From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 0/2] Bulk mem-share identical domains Date: Tue, 6 Oct 2015 15:52:20 +0100 Message-ID: <5613E024.7040901@citrix.com> References: <1443990339-19590-1-git-send-email-tamas@tklengyel.com> <1444141579.5302.199.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZjTbN-0006eV-Ee for xen-devel@lists.xenproject.org; Tue, 06 Oct 2015 14:52:25 +0000 In-Reply-To: <1444141579.5302.199.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Tamas K Lengyel , xen-devel@lists.xenproject.org Cc: Wei Liu , Stefano Stabellini , George Dunlap , Ian Jackson , Jan Beulich , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 06/10/15 15:26, Ian Campbell wrote: > On Sun, 2015-10-04 at 14:25 -0600, Tamas K Lengyel wrote: >> The following patches add a convenience memop to the mem_sharing system, >> allowing for the rapid deduplication of memory pages between identical >> domains. >> >> The envisioned use-case for this is the following: >> 1) Create two domains from the same snapshot using xl. >> This step can also be performed by piping an existing domain's memory >> with >> "xl save -c | xl restore -p " >> It is up for the user to create the appropriate configuration for the >> clone, >> including setting up a CoW-disk as well. >> 2) Enable memory sharing on both domains >> 3) Execute bulk dedup between the domains. > This is a neat trick, but has the downside of first shovelling all the data > over a pipe and then needing to allocate it transiently before dedupping it > again. > > Have you looked at the possibility of doing the save+restore in the same > process with a cut through for the RAM part which just dups the page into > the target domain? > > Once upon a time (migr v1) that would certainly have been impossibly hard, > but with migr v2 it might be a lot easier to integrate something like that > (although surely not as easy as what you've done here!). > > Just an idea, and not intended at all as an argument for not taking this > series or anything. If we are making modifications like this, make something like XEN_DOMCTL_domain_clone which takes a source domid (must exist), pauses it, creates a new domain, copies some state and shares all memory CoW from source to the new domain. This will be far more efficient still than moving all the memory through userspace in dom0. ~Andrew