[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

Jan

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.

   J

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.