[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.