Projects/auto-ballooning

Automatic Ballooning

Introduction

When a Linux host is running out of memory, the kernel will take action to reclaim memory. This action may be detrimental to KVM guests performace (eg. swapping) or even extreme to the point where the kernel may kill a VM or an important virt stack component.

To help avoiding this scenario, a KVM guest could automatically give memory to the host when the host is facing memory pressure. By doing so the guest may also get into memory pressure so we need a way to allow the guest to automatically get memory back.

Design

KVM guests have a driver called the balloon driver. This driver allows guests to shrink and grow their memory. The balloon driver supports two operations:

• Inflate: memory is taken from the guest and given to the host (guest shrinks)
• Deflate: memory is returned from the host to the guest (guest grows)

Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.

Automatic Inflate

Automatic inflate is performed by QEMU (ie. the KVM host). QEMU registers for memory pressure events so that it's notified when the host is under memory pressure.

Current patches have pre-defined values to be used by QEMU when it receives a memory pressure notification from the host kernel. Those values are:

• 1MB on LOW pressure
• 2MB on MEDIUM pressure
• 4MB on CRITICAL pressure

For example, suppose the host is facing MEDIUM pressure and notifies QEMU. When QEMU receives the event, it asks the guest to inflate its balloon by 2MB. The guest in turn will shrink itself by 2MB and give that memory to the host.

Automatic Deflate

Automatic deflate is performed by the guest or, more specifically, by the balloon driver.

The virtio-balloon driver registers a callback with the shrinker API. That callback is called when the guest kernel is facing memory pressure, and the number of pages to be returned to the kernel is passed to the callback. The balloon driver shrink callback deflates the guest's balloon.

For example, suppose the guest shrunk itself because of pressure in the host. But after some time, the guest is running more applications which causes memory pressure in the guest due its reduced size. The guest kernel then starts reclaiming memory and calls all shrink callbacks. That's when the balloon driver's shrink callback runs, and deflates the balloon by the number of pages specified. This causes the guest to grow again.

Testing

You have to do three things to play with automatic-ballooning:

1. Install kernel 3.10 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG
2. Clone QEMU from git://repo.or.cz/qemu/qmp-unstable.git balloon/auto-ballooning/rfc.v2 (or grab the patch here)
3. Install the following kernel on your guest git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/auto-deflate/rfc (or grab the first two patches from the web interface)

After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):

1. Pass -balloon virtio,auto-balloon=true when starting QEMU
2. Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)
3. Switch to QEMU's monitor and shrink guest memory (say from 1G to 200MB)
4. Watch the guest increase its memory by running "info balloon" on QEMU's monitor

To see automatic inflate and automatic deflate in action, you can run several VMs in parallel doing some heavy memory workload. Make sure to over commit host memory. Say your host has 4GB, run 6 VMs with 1GB each.

Another idea is to run one or more VMs in a memory constrained cgroup, although this will require some hacking on the current patches as they register for the root memory cgroup.