On SLES10 we are using simple minded patch that ensures that the admin
accidentally (or inadvertently) does not set the mem value below a
certain minimum value. The goal here is not to guarantee any level of
performance for the applications that may be running when the memory is
throttled down to the lowest minimum value; but rather that we have
enough memory to support the memory management overhead. Since Arvindh
was working on this, I did not submit the patch to xen-devl. If there is
interest, I can submit our patch for this problem.
>>> On Fri, May 19, 2006 at 11:29 am, in message
<20060519152923.GG27262@xxxxxxxxxxxxxxxxxxxxxx>, Ewan Mellor
> On Fri, May 12, 2006 at 12:16:57PM - 0400, Puthiyaparambil, Aravindh
>> This patch causes "xm mem- set" to be lower bound on domX- min- mem
>> in xend- config. Another configuration option called domU- min- mem
>> been introduced, which works similarly to dom0- min- mem. This is
>> users from freezing the system when doing "xm mem- set" on very low
>> values like 32M.
>> Signed- off- by: Aravindh Puthiyaparambil
> I'm not so sure about this one. We've discussed this issue recently,
> there are a number of people (notably some of the guys at IBM) who
> this limit to be imposed by Xend. If you have one VM that you know
> in 16MB, say, then you either need to set domU- min- mem to 0,
> point of having it, or you need to have a "force" flag to override
> domU- min- mem. The latter option here was disliked, because it was
> tools for VM management would just end up using the force flag all
> because they don't know what the domU- min- mem setting is, and
> would defeat the point.
> The min- mem value should be a per- VM setting rather than a Xend
> the check belongs with the tool that's managing VMs for you.
> Xen- devel mailing list
> Xen- devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen- devel
Xen-devel mailing list