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

["Ky Srinivasan" <ksrinivasan@xxxxxxxxxx>]

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.

Regards,

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
came 
>> 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
a 
> floor of 192M is not suitable in all situations.
> 
>> Both these options will break xm- test. So how do you want to
proceed?
> 
> 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
someone 
> to implement a more dynamic scheme (e.g., by hooking off the 
> OOM/low- memory paths, or by slowly allocating memory only when we
can 
> see a reasonable amount of pages available on the free lists).
> 
> I'm rather doubtful that a really good static estimate can be
derived, 
> since it depends so much on particular details of kernel memory
usage. 
> 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
patch 
> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel