KVM - Recent changes [en]

Projects/auto-ballooning

LuizCapitulino — Mon, 17 Jun 2013 21:09:58 GMT

Revision as of 21:09, 17 June 2013		Current revision
Line 5:		Line 5:
	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.		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 situation, a KVM guest could automatically return memory to the host when the host is facing memory pressure (automatic inflate). By doing so the guest may also get into memory pressure so we also need a way to allow the guest to automatically get memory back (automatic deflate).	+	To help avoiding this situation, a KVM guest could automatically return memory to the host when the host is facing memory pressure. By doing so the guest may also get into memory pressure so we also need a way to allow the guest to automatically get memory back.

	That's what the automatic ballooning project is about. The next section will dive into ways of implementing it. The following section will provide instructions on how to try current patches.		That's what the automatic ballooning project is about. The next section will dive into ways of implementing it. The following section will provide instructions on how to try current patches.
Line 20:		Line 20:
	=== Automatic Deflate ===		=== Automatic Deflate ===

-	Automatic deflate is performed by the virtio-balloon driver in the guest. There's also two ways of implementing this:	+	Automatic deflate is performed by the virtio-balloon driver within the guest. There's also two ways of implementing this:

	# The virtio-balloon driver registers a callback with the shrinker API. That callback is called when the guest kernel is facing memory pressure. The number of pages to be returned to the kernel is passed to the callback, so that the callback can deflate the balloon by that amount. This is what the current patchset does		# The virtio-balloon driver registers a callback with the shrinker API. That callback is called when the guest kernel is facing memory pressure. The number of pages to be returned to the kernel is passed to the callback, so that the callback can deflate the balloon by that amount. This is what the current patchset does
Line 26:		Line 26:

	== Testing ==		== Testing ==
		+
		+	You have to do three things to play with automatic-ballooning:
		+
		+	# Install kernel 3.10-rc1 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG
		+	# Clone QEMU from ''git://repo.or.cz/qemu/qmp-unstable.git balloon/auto-ballooning/rfc.v2'' (or grab the patch [http://repo.or.cz/w/qemu/qmp-unstable.git/commit/59fec94e6396d6c32cdce47777440c3a988be63d here])
		+	# 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 patches from the [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])
		+
		+	After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):
		+
		+	# Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU
		+	# Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)
		+	# Switch to QEMU's monitor and decrease guest memory (say from 1G to 200MB)
		+	# Watch the guest increase its memory by repeatedly 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 VM, but generate pressure in the host some way like a big kernel build or an application that allocates lots of memory.

OVMF

Lersek — Sat, 15 Jun 2013 13:44:24 GMT

fix typo in Gerd's name

(Difference between revisions)

Projects/auto-ballooning

LuizCapitulino — Thu, 13 Jun 2013 21:11:26 GMT

Revision as of 21:11, 13 June 2013		Current revision
Line 1:		Line 1:
-	= Auto-ballooning =	+	= Automatic 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).	+	== Introduction ==

-	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).	+	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.

-	The goal of this page is to collect ideas on how to implement auto-ballooning.	+	To help avoiding this situation, a KVM guest could automatically return memory to the host when the host is facing memory pressure (automatic inflate). By doing so the guest may also get into memory pressure so we also need a way to allow the guest to automatically get memory back (automatic deflate).
-	Currently, there is only one proposal, which is the "automatic balance" idea,	+
-	mostly designed by Rik van Riel.	+

-	== Automatic balance ==	+	That's what the automatic ballooning project is about. The next section will dive into ways of implementing it. The following section will provide instructions on how to try current patches.

-	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.	+	== Design ==

-	It's expected that inflate and deflate will balance each other over time.	+	=== Automatic Inflate ===

-	Next sections describe the implementation details of this idea.	+	Automatic inflate is performed by QEMU, that is, the KVM host. There are two ways I'm playing with automatic inflate, in both of them QEMU registers for [http://lwn.net/Articles/544652/ memory pressure] events to learn when the host is under memory pressure:

-	=== auto-inflate ===	+	# QEMU registers for the VMPRESSURE_MEDIUM event and inflates the balloon by an user specified value when the event is received. That value value could default to 16MB or 32MB. This is what the current patchset does
		+	# QEMU registers for the three memory pressure events and inflates the balloon accordingly. Say, it could inflate the balloon by 1MB on VMPRESSURE_LOW; 16MB on VMPRESSURE_MEDIUM and 128MB on VMPRESSURE_CRITICAL. This is not done yet because there's a small limitation in the memory pressure code which doesn't allow this. I'll fix it

-	There are two components needed to make auto-inflate work.	+	=== Automatic Deflate ===

-	* A (host) kernel API to let user-space processes know when the kernel is facing memory pressure	+	Automatic deflate is performed by the virtio-balloon driver in the guest. There's also two ways of implementing this:

-	* QEMU changes to use the host kernel API, and to inflate the guest's balloon when the host kernel is facing memory pressure	+	# The virtio-balloon driver registers a callback with the shrinker API. That callback is called when the guest kernel is facing memory pressure. The number of pages to be returned to the kernel is passed to the callback, so that the callback can deflate the balloon by that amount. This is what the current patchset does
		+	# The virtio-balloon driver registers for an in-kernel memory pressure event (not upstream yet) and deflates the balloon by some fixed amount (maybe the same amount used in automatic inflate)

-	=== auto-deflate ===	+	== Testing ==
-		+
-	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.	+

Multiqueue

Kongove — Thu, 13 Jun 2013 05:44:16 GMT

Revision as of 05:44, 13 June 2013		Current revision
Line 214:		Line 214:

	* ...		* ...
		+
		+	== Enable MQ feature ==
		+	* create tap device with multiple queues, please reference
		+	Documentation/networking/tuntap.txt:(3.3 Multiqueue tuntap interface)
		+	* enable mq in qemu cmdline: -device virtio-net-pci,mq=on,...
		+	* enable mq in guest by 'ethtool -L eth0 combined $queue_num'

	== Test ==		== Test ==

User:ErnestoMT

ErnestoMT — Tue, 11 Jun 2013 14:23:14 GMT

New page

There is nothing to tell about myself really.<br><br>Also visit my web blog :: [http://ralphlaurenpolo4shirts.webs.com/ cheap ralph lauren polo shirts]

NetworkingTodo

Mst — Mon, 10 Jun 2013 07:06:47 GMT

Revision as of 07:06, 10 June 2013		Current revision
Line 105:		Line 105:

	=== projects that are not started yet - no owner ===		=== projects that are not started yet - no owner ===
		+
		+	* Enable GRO for packets coming to bridge from a tap interface
		+
		+	* Better support for windows LRO
		+	Extend virtio-header with statistics for GRO packets:
		+	number of packets coalesced and number of duplicate ACKs coalesced

	* netdev polling for virtio.		* netdev polling for virtio.
Line 195:		Line 201:
	Reduce the number of interrupt		Reduce the number of interrupt

		+	* bridging on top of macvlan
		+	add code to forward LRO status from macvlan (not macvtap)
		+	back to the lowerdev, so that setting up forwarding
		+	from macvlan disables LRO on the lowerdev

		+	* preserve packets exactly with LRO
		+	LRO is not normally compatible with forwarding.
		+	virtio we are getting packets from a linux host,
		+	so we could thinkably preserve packets exactly
		+	even with LRO. I am guessing other hardware could be
		+	doing this as well.

	=== testing projects ===		=== testing projects ===