[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On gio, 2013-05-02 at 15:32 +0100, Tim Deegan wrote:
> Hi,
Hi Tim,

Thanks for looking at this! :-)

> This looks like a promising start.  Two thoughts:
> 1. You currently move memory into a bufferm free it, allocate new memory
>    and restore the contents.  Copying directly from old to new would be
>    significantly faster, and you could do it for _most_ batches:
>    - copy old batch 0 to the backup buffer; free old batch 0;
>    - allocate new batch 1; copy batch 1 directly; free old batch 1;
>      ...
>    - allocate new batch n; copy batch n directly; free old batch n;
>    - allocate new batch 0; copy batch 0 from the backup buffer.
I see what you mean, and I think it's feasible. One thing I noticed (and
not yet tracked down properly, actually) is some sort of "latency" in
freeing the pages... I'll investigate that better and go for what you
suggest if possible.

> 2. Clearing all the _PAGE_PRESENT bits with mmu-update
>    hypercalls must be overkill.  It ought to be possible to drop
>    those pages' typecounts to 0 by unpinning them and then resetting all
>    the vcpus.  The you should be able to just update the contents
>    with normal writes and re-pin afterwards.
Yeah, I thought the same, but haven't found a sensible way of making
that happen yet. However, the 'reset all vcpus' thing definitely needs
more attention (and I'm investigating it right in these days). I'll keep
digging and let you know what I find.

Thanks again,

<<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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.