From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Dario Faggioli <raistlin@linux.it>,
Andre Przywara <andre.przywara@amd.com>,
xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 2 of 2 RFC] xl: allow for moving the domain's memory when changing vcpu affinity
Date: Fri, 6 Jul 2012 14:30:24 +0100 [thread overview]
Message-ID: <4FF6E870.9040702@eu.citrix.com> (raw)
In-Reply-To: <1341581104.32747.43.camel@zakaz.uk.xensource.com>
On 06/07/12 14:25, Ian Campbell wrote:
> On Fri, 2012-07-06 at 13:53 +0100, George Dunlap wrote:
>> On 06/07/12 10:54, Dario Faggioli wrote:
>>> By introducing a new '-M' option to the `xl vcpu-pin' command. The actual
>>> memory "movement" is achieved suspending the domain to a ttemporary file and
>>> resuming it with the new vcpu-affinity
>> Hmm... this will work and be reliable, but it seems a bit clunky. Long
>> term we want to be able to do node migration in the background without
>> shutting down a VM, right? If that can be done in the 4.3 timeframe,
>> then it seems unnecessary to implement something like this.
> We could do something cleverer for HVM (or hybrid) guests to migrate
> pages while the guest is live but migrating a page under a PV guest's
> feet requires quiescing it in the style of a migrate.
>
> We could probably manage to make it such that you just need the
> pause/frob/unpause phases without actually writing RAM to disk, and that
> infrastructure might be useful for other reasons I suppose. (e.g. I
> think bad page offlining currently uses a similar save/restore trick)
Yes, I think doing this chunks at a time is likely to be much
preferrable to writing the whole thing to disk and reading it out
again. Doing it "live" may end up with more total overhead, but it
wont' require the VM being actually down for the suspend/resume cycle,
which on a large guest may be tens of seconds.
-George
next prev parent reply other threads:[~2012-07-06 13:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-06 9:54 [PATCH 0 of 2 RFC] xl: move domeins among NUMA nodes Dario Faggioli
2012-07-06 9:54 ` [PATCH 1 of 2 RFC] xl: parse extra_config options even when restoring Dario Faggioli
2012-07-06 9:54 ` [PATCH 2 of 2 RFC] xl: allow for moving the domain's memory when changing vcpu affinity Dario Faggioli
2012-07-06 12:53 ` George Dunlap
2012-07-06 13:25 ` Ian Campbell
2012-07-06 13:30 ` George Dunlap [this message]
2012-07-06 13:38 ` Ian Campbell
2012-07-06 14:05 ` Dario Faggioli
2012-07-06 14:07 ` George Dunlap
2012-07-06 14:42 ` Ian Campbell
2012-07-06 13:57 ` Dario Faggioli
2012-07-06 14:04 ` George Dunlap
2012-07-06 14:14 ` Dario Faggioli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FF6E870.9040702@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=andre.przywara@amd.com \
--cc=raistlin@linux.it \
--cc=xen-devel@lists.xen.org \
--cc=yang.z.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).