[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
Hi, Tim: Sorry for late reply, since I am thinking about some design issues. On Fri, Dec 10, 2010 at 5:57 PM, Tim Deegan <Tim.Deegan@xxxxxxxxxx> wrote: Hi, I am using the gmail, but don't see any config for this. It should be indented and prefixed by the symbol '|', isn't it?
I see. So you are saying that type_count is providing some kind of protection on refcount? If that's the case, I will just add a small piece of code to recover type_info when the check of count_info fails.
First, the patch from the above URL seems to work on the unstable version, which calls qemu_invalidate_map_cache() to drop the count down to 1 for qemu mapped pages. But the patch is not currently in the unstable version. 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? 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? 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) Afterwards, when COW happens, the unshare() operation uses domain_id and gfn to find the page_info, then uses the inner checksum value to search hash list. Everything seems fine, but the tradeoff is to change the blktap2 code for this new interface.
Thanks for the remind! I will make sure they are unmapped properly. Bests, Jui-Hao _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |