| |||||||||||||
|
| |||||||||||||
Transcendent memoryTranscendent memoryPosted Jul 8, 2009 20:57 UTC (Wed) by elanthis (subscriber, #6227)In reply to: Transcendent memory by johill Parent article: Transcendent memory
Sharing data between the guests. If both guests have an identical binary loaded up from their identical page cache of their identical read only /usr, why copy it into memory twice and waste the space and incur the cache/copying/performance overhead?
(Log in to post comments)
Transcendent memory Posted Jul 9, 2009 0:44 UTC (Thu) by johill (subscriber, #25196) [Link]
I don't see how that's possible with this API though. Or rather, how the API has any influence on it.
See, if the host were to hash the pages I gave it (from the guest) with this API, and memcmp() them, it could with very little effort tell me it's stored it even though it just made a note that my ID(s) point to that particular page, and refcounted the page. This is easy since a page, once pushed from the guest to the host, is immutable.
The way the article was written though it seems that with the shared stuff, different hosts could access the same page frame by the same ID. So guest A could push out a page and guest B could retrieve it with that same ID? Where's the use in that?
Transcendent memory Posted Jul 9, 2009 0:59 UTC (Thu) by ncm (subscriber, #165) [Link]
If the client were responsible for hashing the page contents to produce the UUID, then the kernel wouldn't have to do it; it could rely on the UUID itself to identify sharable pages automatically.
Transcendent memory Posted Jul 9, 2009 14:35 UTC (Thu) by johill (subscriber, #25196) [Link] That
Transcendent memory Posted Jul 11, 2009 16:04 UTC (Sat) by MarkWilliamson (guest, #30166) [Link]
How about for implementing a shared in-memory filesystem that multiple guests can retrieve information from? The filesystem itself might have been created by a third-party "trusted" VM or the hypervisor itself.
|
|
||||||||||||