WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH][Xen 4.0-testing.hg] fix small bugs of memory sha

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