Re: [PATCH] Prevent changing a memory size of Domain-0 evenif users make a careless mistake

[Jeremy Fitzhardinge <jeremy@goop.org>]

Jan Beulich wrote:
>>>> Masaki Kanno <kanno.masaki@jp.fujitsu.com> 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