Re: [Xen-devel] [PATCH 0/2] Bulk mem-share identical domains

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Oct 06, 2015 at 10:05:12AM -0600, Tamas K Lengyel wrote:
> On Tue, Oct 6, 2015 at 8:26 AM, Ian Campbell <ian.campbell@xxxxxxxxxx>
> 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 <domain> <pipe> | xl restore -p <new_cfg> <pipe>"
> > >    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.
> >
> 
> Precisely.
> 
> 
> >
> > 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?
> >
> 
> I have, but I have to stay untangling the internals of xl is pretty
> daunting..
> 
> 
> >
> > 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.
> >
> 
> So another trick that works pretty well for PV domains is to simply create
> them paused:
>    xl create -p <cfg>
> 
> This takes pretty much no time and can be followed up by the bulk memory
> deduplication. The clone is fully functional afterwards.
> Unfortunately for HVM domains this is not sufficient as QEMU needs to be
> setup as well, for which right now only xl restore works. I experimented
> with saving the QEMU state separately, creating the paused HVM domain,
> killing it's qemu process, then starting a new one with the exact same
> parameters but with the extra -loadvm flag (reserving an extra page plus
> trying to wire up the hvmparams). Unfortunately this still crashes the
> guest after unpause so I'm pretty much stuck on that side. So yea, any help
> with that would be greatly appreciated ;) If there was an xl option to do
> what "xl restore" is doing, but to only load the QEMU state, that would be
> awesome.
> 

In case you miss it, there is now soft-reset support which dumps all
memory plus various states from one domain to another, and toolstack
will take care of QEMU and various userspace bits. This might be useful
to you?

To be clear, this is just FYI, not suggesting we block this series.

Wei.

> Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel