Re: [Xen-devel] [PATCH 6 of 8 [RFC]] libxc: introduce xc_domain_move_memory

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On mar, 2013-04-09 at 06:23 +0100, Juergen Gross wrote:
> On 09.04.2013 04:49, Dario Faggioli wrote:
> > as a mechanism of deallocating and reallocating (immediately!) _all_
> > the memory of a domain. Notice it relies on the guest being suspended
> > already, before the function is invoked.
> 
> Is this solution intended to be the final one?
> 
Well, the idea of sharing the patches, even at this stage, was right
about discussing that! :-P

> This might be okay for a domain with less than 1GB of memory, but I see
> problems for really huge domains. The needed time to copy the memory might
> result in long offline times. 
>
I see what you mean. I thought about approaches that copy only a
specific part of the memory, perhaps according to some usage statistics.

I've not yet abandoned that idea, but I honestly think that, if we go
through the suspend-copy-resume (which is pretty much the only thing I
can do with PV guests, isn't it?), that can't be for a page or two, or
the impact of the overhead would be even higher!

> For this case something like live migration
> (optional?) would be a better solution, I think.
> 
Well, I thought about that too, and I'm open to
thinking/discussing/hearing suggestions about how to implement a "live
phase" for this.

The problem is, with a more migration-alike approach, I'll end up
doubling the memory requirements of, potentially, all the domains (since
I'd need space for storing the full RAM image of each one!), which I
don't think it is an acceptable requirement either, _especially_ for big
guests, is it? :-(

Thanks for you interest, :-)
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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