RE: [Xen-devel] [RFC][PATCH] 0/9 Populate-on-demand memory

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx] 
>Sent: Wednesday, December 24, 2008 11:35 PM
>
>> We could to allocate a new page at that point; but it's likely that
>> the allocation will fail unless there happens to be memory lying
>> around somewhere, not used by dom0 or any other doamin.  And if that
>> were the case, why not just start it with that much memory to begin
>> with?
>
>Actually, if dom0_mem is used rather than the default of letting
>domain0 absorb all free memory and dole it as needed to launching
>VMs, there will almost always be some memory lying around.

I recall some previous discussion to have explicit dom0_mem
setting instead of blindly giving all memory to dom0. How about
others' preferrence on this option? At least another benefit to
limit dom0_mem size, iirc, is about numa node aware memory
allocation. Currently Xen could allocate memory by taking node
factor into consideration, but once all memories are allocated 
to dom0 in the start, it'd be much more complex since balloon
driver is not node aware and thus can't selectively give back
pages from dom0, which then nullify xen's node aware allocator.

>
>And in the not-to-distant future, when live migration is
>more widely used, there had better be memory lying around
>or migration won't work.

live migration seems orthogonal here, since new domain is
created and the condition doesn't change as long as dom0
has enough memory to balloon back. :-)

>
>As for "why not just start it with that much memory to begin
>with?"... because in most environments VMs are sized once
>(e.g. 512MB) and almost never changed... because sysadmins
>rarely want to be bothered with constantly fine tuning
>just to use an extra spare few MB of memory.
>
>That's why your patch is so important!

Agree.

Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel