[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH][Xen 4.0-testing.hg] fix small bugs of memory sharing
At 09:55 +0000 on 15 Dec (1292406915), Jui-Hao Chiang wrote: > As for where to put the code for duplicate pages, we wonder to do that > in workqueue or some other thread-like things. Since this is a > periodic running procedure, and definitely takes a long > time. Originally we want to put it in dom0 user-level as a daemon, but > there are not enough page information there. So it seems better to put > inside hypersior. Do you have any other suggestion? I would avoid putting it in the hypervisor on general principle. Anything that can live in the tools should live in the tools. > One more thing is about the design part. > (1) The current memory sharing code uses a unique 64-bit handle number to > identify a page/mfn, and use this handle to index into the hash list. > (2) The page nomination makes the page type as p2m_ram_shared (read-only), > and return the handle to user, e.g. blktap2. > (3) Later on, the user calls mem_sharing_share_pages(handle1, handle2) by > giving two handles. Note that, the code doesn't do any comparison of page > content but leave this task to users whereas the only user we know is blktap2 > with qcow disk format configured. > But why not let the memory sharing code to do the content comparison? Is > there any user who wants to share two pages with different content? > No, but since the userspace tool already knows what it's doing there's no need for Xen to compare the pages. It would just make it slower. > In order to perform the page comparison, we need to compute checksum value > for the page content (or even md5, sha1..), and use this checksum value to > index into a hash list. It seem feasible to replace the handle number with > the checksum value of page, and combine the nominate() and share() operations > together in one function as the following steps: > (1) Mark the page as p2m_ram_shared > (2) Compute the checksum of a page > (3) Search in the hash list, if some page with the same checksum value is > found, a real byte-by-byte memory compasion is performed. > (4) If content is totally matched, perform the share() operation by removing > one duplicated page/mfn. > (5) Record this checksum value in page_info->shr_handle (used to store the > handle) That's potentially a very expensive operation to do in a single hypercall. Also, how would you choose which pages to nominate? Just comparing every page with avery other page is O(n^2), and if you have a better scheme (like Grzegorz's one of checking pages as they're loaded) then you should use that instead of searching for a match in all of memory. Of course, you could do all the checksums and comparisons from userspace using the existing interfaces, without adding more mechanism in Xen. Cheers, Tim. -- Tim Deegan <Tim.Deegan@xxxxxxxxxx> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |