Re: [Xen-devel] How does the self-ballooning daemon calculate the selftarget?

[Jia Rao <rickenrao@xxxxxxxxx>]

Hi Dan,

Thanks for the reply.
The XENBALLOON_MINMEM was set to 0 in my case.

I am wondering if the /proc/meminfo is a reliable source for memory utilization of a guest. In my case, the guest stays in idle for several hours, the metrics in /proc/meminfo is seldom changed.
For example, the Committed_AS and Active metrics stay almost the same for several hours.

In earlier kernels, the Active and Inactive metrics are periodically updated by a kernel thread kscand, which seems to has been removed from the 2.6 kernel. 

From what I have observed, the meminfo is correctly updated if the memory demand from the guest is increasing. However, once the memory demand drops or be almost zero (idle), the meminfo is not periodically updated. This might be a problem for the self-balloon daemon to deflate the balloon.

Thanks,
Jia

On Tue, Nov 10, 2009 at 12:43 PM, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:

Hi Jia --

There are changes in newer versions of the balloon driver to
ensure that ballooning does not take too much memory away
from the kernel, which would result in kernel crashes.
These changes set a different minimum value depending on
how much memory the kernel originally discovered.

If the self-ballooning scripts run with an "old" balloon
driver and one changes certain parameters
in the scripts, kernel crashes might occur.  So the
self-ballooning scripts implement a minimum memory
algorithm similar to the newer balloon driver to
avoid this situation.

Look for XENBALLOON_MINMEM in the xenballoon config file
if you want to change this.

Dan

-----Original Message-----
From: Jia Rao [mailto:rickenrao@xxxxxxxxx]
Sent: Tuesday, November 10, 2009 9:23 AM
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] How does the self-ballooning daemon calculate the selftarget?


Hi all,

I am wondering how does the self-ballooning daemon calculate the selftarget for the guest OS.
>From the README of balloon driver, it seems that selftarget is determined by Committed_AS in meminfo.

I did some test on tpcc benchmark. the OS is initially allocated 2048MB of memory, and then I enabled the selfballooning by echo 1 > /proc/xen/balloon.
The configuration of xenballoond.conf is the default except that I enabled self-balloon.

The following is the meminfo

MemTotal:      1939996 kB
MemFree:       1183888 kB
Buffers:         13260 kB
Cached:         396492 kB
SwapCached:          0 kB
Active:         386912 kB
Inactive:       213584 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      1939996 kB
LowFree:       1183888 kB
SwapTotal:     2097136 kB
SwapFree:      2097132 kB
Dirty:           78432 kB
Writeback:           0 kB
AnonPages:      190668 kB
Mapped:          14228 kB
Slab:            53148 kB
PageTables:       4836 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   3067132 kB
Committed_AS:   524484 kB
VmallocTotal: 34359738367 kB
VmallocUsed:      1208 kB
VmallocChunk: 34359737159 kB

It seems that the self-balloon driver is reluctant to give up free memory from the guest although the Committed_AS is small. The self-ballooning did changed the selftarget to something like 1.6GB but quickly changed to and fix at 193xxxxKB.

According to the meminfo, we should be able to give up at least 800MB back to the VMM.
FYI: xen 3.3.1, linux 2.6.18.8 in both dom0 and domu.

Any ideas?

Thanks,
Jia

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