WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: 'Dan Magenheimer' <dan.magenheimer@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [RFC][PATCH] 0/9 Populate-on-demand memory
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 25 Dec 2008 10:47:32 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 24 Dec 2008 18:48:29 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <30c85335-4729-4ae4-bb24-0c9dc2abe3cf@default>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <de76405a0812240642i42f9c1f2ud7ca7d9d1bf4e400@xxxxxxxxxxxxxx> <30c85335-4729-4ae4-bb24-0c9dc2abe3cf@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acll3WEE9fCgRc51Q6KQp2fE6IzQ2gAXD2Ow
Thread-topic: [Xen-devel] [RFC][PATCH] 0/9 Populate-on-demand memory
>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