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


[Xen-devel] Re: [PATCH][BALLOON] Fix minimum target

The idea was to have in place a structure that allowed for some
experimentation on exactly what the floor needs to be and what the
minimum memory slope needs to be.  An earlier version of my patch
attempted to classify machines based on the maximum amount of memory
that it would ever handle. For each class the minimum memory was still a
linear function with the slope and the floor being dependent on the
maximum amount of memory that the domain would handle. Another approach
I was considering was to base the amount of minimum memory on the amount
of free memory a domain has. This strategy may give us a reasonably
functional system when the domain is ballooned down while it may result
in a minimum that could be potentially higher than an approach that we
have been playing with might yield.


K. Y

>>> On Sat, May 27, 2006 at  6:46 pm, in message
<fe38b039cfc2775cdaa555c35a441c94@xxxxxxxxxxxx>, Keir Fraser
<Keir.Fraser@xxxxxxxxxxxx> wrote: 

> On 27 May 2006, at 21:34, Puthiyaparambil, Aravindh wrote:
>> Dom0 needs a much bigger floor of 192M. I think this is where KY
>> up
>> with the 192M number. I know this will cause problems on machines 
>> coming
>> up with dom0_mem<192M.
> That being the case (which it certainly is) it is pretty obvious that
> floor of 192M is not suitable in all situations.
>> Both these options will break xm- test. So how do you want to
> If there isn't a suitable static minimum which prevents OOM death on

> most systems without also impacting the useful lower range of 
> ballooning on other systems then I think we'll have to wait for
> to implement a more dynamic scheme (e.g., by hooking off the 
> OOM/low- memory paths, or by slowly allocating memory only when we
> see a reasonable amount of pages available on the free lists).
> I'm rather doubtful that a really good static estimate can be
> since it depends so much on particular details of kernel memory
> Given the results of these experiments I'm tempted to remove the 2% 
> minimum that is already in the tree --  vendors can make their own
> if they have a better idea of what works for their particular kernel

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

Xen-devel mailing list