Re: [PATCH] Add a page cache-backed balloon device driver.

On Mon, Sep 10, 2012 at 2:04 PM, Rik van Riel [off-list ref] wrote:

On 09/10/2012 01:37 PM, Mike Waychison wrote:

quoted

On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin [off-list ref]
wrote:

quoted

quoted

Also can you pls answer Avi's question?
How is overcommit managed?

Overcommit in our deployments is managed using memory cgroups on the
host.  This allows us to have very directed policies as to how
competing VMs on a host may overcommit.

How do your memory cgroups lead to guests inflating their balloons?

The control loop that is driving the cgroup on the host can still move
the balloon target page count causing the balloon in the guest to try
and inflate.  This allows the host to effectively slowly grow the
balloon in the guest, allowing reclaim of guest free memory, followed
by guest page cache (and memory on the host system).  This can then be
compared with the subsequent growth (as this balloon setup allows the
guest to grow as it sees fit), which in effect gives us a memory
pressure indicator on the host, allowing it to back-off shrinking the
guest if the guest balloon quickly deflates.

The net effect is an opportunistic release of memory from the guest
back to the host, and the ability to quickly grow a VM's memory
footprint as the workload within it requires.

This dynamic memory sizing of VMs is much more in line with what we
can expect from native tasks today (and which is what our resource
management systems are designed to handle).