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/
Home Products Support Community News


Re: [Xen-devel] [PATCH] Prevent changing a memory size of Domain-0 eveni

To: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Prevent changing a memory size of Domain-0 evenif users make a careless mistake
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Fri, 04 Apr 2008 08:06:49 -0700
Cc: Ky Srinivasan <KSrinivasan@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>, Kurt Garloff <garloff@xxxxxxx>
Delivery-date: Fri, 04 Apr 2008 08:08:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <47F61CFA.76E4.0078.0@xxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4EC8963B84D19Akanno.masaki@xxxxxxxxxxxxxx> <47F61CFA.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20080315)
Jan Beulich wrote:
Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx> 04.04.08 12:06 >>>
If users accidentally change a memory size of Domain-0 to very small memory size by xm mem-set command, users will be not able to operate Domain-0. I think that Domain-0 is important for Xen, so I'd like to prevent the accident by xm mem-set command.

Each domain, in my opinion, should also be able to protect itself from
being ballooned down too much. We have been carrying a respective
patch for quite a while. Since originally it wasn't written by me, I never
tried to push it. Nevertheless, I'm showing it below to see whether
others would think it makes sense.


From: ksrinivasan@xxxxxxxxxx Subject: Don't allow ballooning down a domain below a reasonable limit.
References: 172482

Reasonable is hard to judge; we don't want to disallow small domains.
But the system needs a reasonable amount of memory to perform its
duties, set up tables, etc. If on the other hand, the admin is able
to set up and boot up correctly a very small domain, there's no point
in forcing it to be larger.
We end up with some kind of logarithmic function, approximated.

Hm, I've been bitten by this myself quite a lot lately, so I'm sympathetic to a patch like this. In the 2.6 pvops balloon driver, I'm using hotplug memory to extend the page structures, rather than relying on statically preallocating them at boot. This means that max_pfn isn't terribly meaningful, since there's no fixed upper limit.

I was thinking along the lines of having the balloon thread pay attention to how much free (lowmem) memory is actually available, and stop processing if it drops below some threshold. That gives the VM some time to deal with the memory pressure (swap things out, etc), without making things OOM-killer critical. And if the VM can't free up any more memory, then we can't force it beyond that. The processing rate could be proportional to the amount of free memory rather than a hard go/no-go switch to make things a bit smoother.


Xen-devel mailing list