Re: [Xen-devel] [PATCH] linux/balloon: don't allowballooningdowna domain below a reasonable limit

[Markus Hochholdinger <Markus@xxxxxxxxxxxxxxxxx>]

Hi,

Am Dienstag, 13. Mai 2008 00:19 schrieb Ian Pratt:
> > I was planning on providing both Model C and Model D (see below),
> > but let me know if you will only accept Model C (or even Model B)
> > and I will adjust accordingly.
> I think all these models are wrong :-)
> 'free' guest memory is often serving useful purposes such as acting as a
> buffer cache etc, so ballooning it out unnecessarily is probably not a
> good thing. Model D might work better if we had a way of giving up
> memory in a way that wasn't 'final' i.e. we could surrender pages back
> to xen, but would get a ticket with which we could ask Xen if it still
> had the page, and if xen hadn't zeroed them and handed them to someone
> else we could get the original page back. Hence, we could treat pages
> handed back to xen as a kind of 'unreliable swap device'.

i'm running older Xen 3.0.3 and i do the balloning manual by myself. My manual 
considerations are based on
* real used memory (used - buffers - cache)
* real free memory (without buffers and without cache)
Real free memory should be given away instantly because it's really not used.
In normal situation i give a domU twice the real used memory so the domU can 
use cache and buffers.
If i need more ram, i'm looking how much in the domUs is swapped. I take away 
more memory from domUs which have not used swap till they began to swap.

As i've better data (rrd graphs for a long period) as xen can have, i can 
better consider the need for a longer period.

But perhaps something like the following could be used:
* Minimum memory should be at least the real used memory plus 10 percent of
  this.
* Maximum memory should be given in configuration file to better adjust memory
  manual. Alternative the maximum memory should be twice the real used memory.
* For memory pressure:
  Let xen adjust between min and max memory. Say we have a value of x between
  min and max memory for each domU. Let xen give the same percent of each x
  for each domU until all memory is fully used or the needed memory (for
  perhaps starting a new domU) is free. (The percentage could climb over 100%
  if a lot of memory is available and the domUs need them.)
* For a lot of free memory:
  Let xen adjust memory towards maximum memory, but don't let more than 10
  percent of total memory be free.

The use of percentage across the domUs should better balance between little 
(e.g. 64MB) and big (e.g. 8096MB) domUs. If a lot of swap is used in a domU 
and the domU gets more ram, the domU will automatically move swap to ram as 
more ram arrives. If a lot of swap is allocated but not heavily used it will 
perhaps not influence the performance much and also it will not influence 
memory distribution.

I know i'm no kernel hacker and perhaps my assumptions are stupid from the 
view of a hacker. But this is what i do manually in real life and works very 
well for me (for about one hundred domUs) so i hope this could be helpful for 
the people coding the auto balloning stuff?


-- 
greetings

eMHa

pgpEJIidSBVh1.pgp
Description: PGP signature

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