From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH] Prevent changing a memory size of Domain-0 evenif users make a careless mistake Date: Fri, 04 Apr 2008 08:06:49 -0700 Message-ID: <47F64409.7090202@goop.org> References: <4EC8963B84D19Akanno.masaki@jp.fujitsu.com> <47F61CFA.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <47F61CFA.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: Ky Srinivasan , xen-devel@lists.xensource.com, Masaki Kanno , Kurt Garloff List-Id: xen-devel@lists.xenproject.org Jan Beulich wrote: >>>> Masaki Kanno 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. > > Jan > > From: ksrinivasan@novell.com > 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. J