Revision as of 09:03, 12 December 2012

Auto-ballooning

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 kills user-space processes (which could be a kvm guest itself or a virt stack component).

To help avoiding this situation, a kvm guest could automatically inflate its balloon (thus returning memory to the host) when the host is facing memory pressure. Likewise, a kvm guest could automatically deflate its balloon when the guest itself is facing memory pressure (maybe due to automatic inflate).

The goal of this page is to collect ideas on how to implement auto-ballooning. Currently, there is only one proposal, which is the "automatic balance" idea, mostly designed by Rik van Riel.

Automatic balance

In automatic balance, the hypervisor (eg. QEMU) must have a way to detect that the host is under memory pressure. When this happens, QEMU could automatically inflate the guest's balloon to some value (say 10MB). When it's the guest that's facing memory pressure, its balloon driver could automatically deflate the memory balloon.

It's expected that inflate and deflate will balance each other over time.

Next sections describe the implementation details of this idea.

auto-inflate

There are three components needed to make auto-inflate work.

A host kernel API to let user-space processes know when the kernel is facing memory pressure (TODO: point to mempressure API)

QEMU changes to use the host kernel API, and to inflate the guest's balloon when the host kernel is facing memory pressure

auto-deflate

Only one component is needed for auto-deflate:

The guest virtio-balloon driver must be changed to automatically deflate the balloon when the guest is facing memory pressure

status

FIXME: add tree.

testing

FIXME: describe.

@@ Line 1: / Line 1: @@
 = Auto-ballooning =
-When a kvm host is running out of memory, the host 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 kills user-space processes (which could be a kvm guest itself or a virt stack component).
+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 kills user-space processes (which could be a kvm guest itself or a virt stack component).
-To help avoiding those scenarios, the hypervisor (eg. QEMU) could automatically inflate the guest's balloon (thus returning memory to the host). This will also require a method for automatically deflating the guest's memory, so that fairness is ensured and the guest kernel doesn't run itself into trouble.
+To help avoiding this situation, a kvm guest could automatically inflate its balloon (thus returning memory to the host) when the host is facing memory pressure. Likewise, a kvm guest could automatically deflate its balloon when the guest itself is facing memory pressure (maybe due to automatic inflate).
 The goal of this page is to collect ideas on how to implement auto-ballooning.
@@ Line 11: / Line 11: @@
 == Automatic balance ==
-In automatic balance, the hypervisor (eg. QEMU) automatically inflates the guest balloon when the host kernel is under memory pressure. On the other hand, when the guest kernel is under memory pressure, it will automatically try to deflate its balloon (which possibly may have been inflated by the hypervisor).
+In automatic balance, the hypervisor (eg. QEMU) must have a way to detect that the host is under memory pressure. When this happens, QEMU could automatically inflate the guest's balloon to some value (say 10MB). When it's the guest that's facing memory pressure, its balloon driver could automatically deflate the memory balloon.
-It's expected that inflate and deflate will automatically balance each other over time.
+It's expected that inflate and deflate will balance each other over time.
 Next sections describe the implementation details of this idea.

Projects/auto-ballooning: Difference between revisions