https://linux-kvm.org/api.php?action=feedcontributions&feedformat=atom&user=LuizCapitulino 2026-04-05T23:14:57Z User contributions MediaWiki 1.39.5 https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=5024 2014-01-23T20:49:37Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> The virtio balloon device allows KVM guests to reduce their memory size (thus relinquishing memory to the host) and to increase it back (thus taking memory from the host).<br /> <br /> This feature is mainly intended to support over-committing memory on KVM hosts. That is, hosts that are running VMs whose total memory size is greater than what the host has physically available. For example, a 2G host running two VMs each with 2G would be over-committed.<br /> <br /> The balloon device is important to support memory over-commitment because it allows for reducing a guest's memory size if needed. Suppose, in the previous example, that one of the guests is using 1G and its other 1G is free. We could use the balloon device to reduce this guest's size from 2G to 1G, this would free 1G in the host allowing the other VM to use it. Of course, if the reduced guest wants to run an application that consumes more than the 1G it currently has, it has to grow again.<br /> <br /> That's the problem with the current balloon device, it's entirely manual. Someone (or some tool) is supposed to be watching the pressure in the host and guest and then operate the balloon accordingly. This doesn't work well in practice (if doable at all).<br /> <br /> The balloon has to be automatic in order to be really useful. It could like this: when the host is under pressure, it asks guests to relinquish some megas if they can. When/if a guest gets into memory pressure, it gets some megas back from the host. That's what the automatic ballooning series is about.<br /> <br /> === KVM Forum 2013 presentation slides ===<br /> <br /> They can be found [http://www.linux-kvm.org/wiki/images/f/f6/Automatic-ballooning-slides.pdf here], but note that much has changed since this talk.<br /> <br /> == Patches and Git trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''Guest kernel:''' [http://marc.info/?l=kvm&amp;m=138988948715638&amp;w=2 RFC PATCH 0/4 virtio_balloon: add pressure notification via a new virtqueue]<br /> <br /> '''QEMU:''' [http://marc.info/?l=kvm&amp;m=138988966315690&amp;w=2 RFC PATCH balloon: add automatic ballooning support]<br /> <br /> === Git trees ===<br /> <br /> '''Guest kernel:'''<br /> <br /> [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git git://repo.or.cz/linux-2.6/luiz-linux-2.6.git] virtio-balloon/pressure-notification/rfc/v1<br /> <br /> '''QEMU:'''<br /> <br /> [http://repo.or.cz/w/qemu/qmp-unstable.git git://repo.or.cz/qemu/qmp-unstable.git] balloon-automatic/handle-all-events/rfc/v1<br /> <br /> == TODO ==<br /> <br /> * More performance tests<br /> * Make it dynamic to enable/disable automatic ballooning<br /> * Do kernel work required in order to have non-cgroups code using in-kernel memory pressure notification<br /> <br /> == Testing ==<br /> <br /> Setup:<br /> <br /> # Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled<br /> # Build QEMU from [[#Git trees| the Git trees section]]<br /> # Build and install the guest kernel from [[#Git trees| the Git trees section]]<br /> <br /> Then start qemu with:<br /> <br /> &lt;nowiki&gt; # qemu [...] -device virtio-balloon,automatic=true&lt;/nowiki&gt;<br /> <br /> To see automatic ballooning in action, do the following:<br /> <br /> # Generate pressure in your host (like running several VMs in parallel); or connect to QMP and issue the ''balloon-inject-host-pressure'' command<br /> # You can monitor automatic ballooning activity by issuing ''info balloon'' in QEMU's monitor (also, I have debug code enabled that will dump a lot of info to stdout when &quot;info balloon&quot; is issued)<br /> # After the guest has shrinked a bit, you can generate pressure in the guest to see it increasing its size again</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=5021 2014-01-20T18:32:09Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> The virtio balloon device allows KVM guests to reduce their memory size (thus relinquishing memory to the host) and to increase it back (thus taking memory from the host).<br /> <br /> This feature is mainly intended to support over-committing memory on KVM hosts. That is, hosts that are running VMs whose total memory size is greater than what the host has physically available. For example, a 2G host running two VMs each with 2G would be over-committed.<br /> <br /> The balloon device is important to support memory over-commitment because it allows for reducing a guest's memory size if needed. Suppose, in the previous example, that one of the guests is using 1G and its other 1G is free. We could use the balloon device to reduce this guest's size from 2G to 1G, this would free 1G in the host allowing the other VM to use it. Of course, if the reduced guest wants to run an application that consumes more than the 1G it currently has, it has to grow again.<br /> <br /> That's the problem with the current balloon device, it's entirely manual. Someone (or some tool) is supposed to be watching the pressure in the host and guest and then operate the balloon accordingly. This doesn't work well in practice (if doable at all).<br /> <br /> The balloon has to be automatic in order to be really useful. It could like this: when the host is under pressure, it asks guests to relinquish some megas if they can. When/if a guest gets into memory pressure, it gets some megas back from the host. That's what the automatic ballooning series is about.<br /> <br /> === KVM Forum 2013 presentation slides ===<br /> <br /> They can be found [http://www.linux-kvm.org/wiki/images/f/f6/Automatic-ballooning-slides.pdf here], but note that much has changed since this talk.<br /> <br /> == Patches and Git trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''Guest kernel:''' [http://marc.info/?l=kvm&amp;m=138988948715638&amp;w=2 RFC PATCH 0/4 virtio_balloon: add pressure notification via a new virtqueue]<br /> <br /> '''QEMU:''' [http://marc.info/?l=kvm&amp;m=138988966315690&amp;w=2 RFC PATCH balloon: add automatic ballooning support]<br /> <br /> === Git trees ===<br /> <br /> '''Guest kernel:'''<br /> <br /> [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git git://repo.or.cz/linux-2.6/luiz-linux-2.6.git] virtio-balloon/pressure-notification/rfc.v1<br /> <br /> '''QEMU:'''<br /> <br /> [http://repo.or.cz/w/qemu/qmp-unstable.git git://repo.or.cz/qemu/qmp-unstable.git] balloon-automatic/handle-all-events/rfc.v1<br /> <br /> == TODO ==<br /> <br /> * More performance tests<br /> * Make it dynamic to enable/disable automatic ballooning<br /> * Do kernel work required in order to have non-cgroups code using in-kernel memory pressure notification<br /> <br /> == Testing ==<br /> <br /> Setup:<br /> <br /> # Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled<br /> # Build QEMU from [[#Git trees| the Git trees section]]<br /> # Build and install the guest kernel from [[#Git trees| the Git trees section]]<br /> <br /> Then start qemu with:<br /> <br /> &lt;nowiki&gt; # qemu [...] -device virtio-balloon,automatic=true&lt;/nowiki&gt;<br /> <br /> To see automatic ballooning in action, do the following:<br /> <br /> # Generate pressure in your host (like running several VMs in parallel); or connect to QMP and issue the ''balloon-inject-host-pressure'' command<br /> # You can monitor automatic ballooning activity by issuing ''info balloon'' in QEMU's monitor (also, I have debug code enabled that will dump a lot of info to stdout when &quot;info balloon&quot; is issued)<br /> # After the guest has shrinked a bit, you can generate pressure in the guest to see it increasing its size again</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=5020 2014-01-20T18:30:24Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> The virtio balloon device allows KVM guests to reduce their memory size (thus relinquishing memory to the host) and to increase it back (thus taking memory from the host).<br /> <br /> This feature is mainly intended to support over-committing memory on KVM hosts. That is, hosts that are running VMs whose total memory size is greater than what the host has physically available. For example, a 2G host running two VMs each with 2G would be over-committed.<br /> <br /> The balloon device is important to support memory over-commitment because it allows for reducing a guest's memory size if needed. Suppose, in the previous example, that one of the guests is using 1G and its other 1G is free. We could use the balloon device to reduce this guest's size from 2G to 1G, this would free 1G in the host allowing the other VM to use it. Of course, if the reduced guest wants to run an application that consumes more than the 1G it currently has, it has to grow again.<br /> <br /> That's the problem with the current balloon device, it's entirely manual. Someone (or some tool) is supposed to be watching the pressure in the host and guest and then operate the balloon accordingly. This doesn't work well in practice (if doable at all).<br /> <br /> The balloon has to be automatic in order to be really useful. It could like this: when the host is under pressure, it asks guests to relinquish some megas if they can. When/if a guest gets into memory pressure, it gets some megas back from the host. That's what the automatic ballooning series is about.<br /> <br /> === KVM Forum 2013 presentation slides ===<br /> <br /> They can be found [http://www.linux-kvm.org/wiki/images/f/f6/Automatic-ballooning-slides.pdf here], but note that much has changed since this talk.<br /> <br /> == Patches and Git trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''Guest kernel:''' [http://marc.info/?l=kvm&amp;m=138988948715638&amp;w=2 RFC PATCH 0/4 virtio_balloon: add pressure notification via a new virtqueue]<br /> <br /> '''QEMU:''' [http://marc.info/?l=kvm&amp;m=138988966315690&amp;w=2 RFC PATCH balloon: add automatic ballooning support]<br /> <br /> === Git trees ===<br /> <br /> '''Guest kernel:'''<br /> <br /> [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git git://repo.or.cz/linux-2.6/luiz-linux-2.6.git] virtio-balloon/pressure-notification/rfc.v1<br /> <br /> '''QEMU:'''<br /> <br /> [http://repo.or.cz/w/qemu/qmp-unstable.git git://repo.or.cz/qemu/qmp-unstable.git] balloon-automatic/handle-all-events/rfc.v1<br /> <br /> == Testing ==<br /> <br /> Setup:<br /> <br /> # Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled<br /> # Build QEMU from [[#Git trees| the Git trees section]]<br /> # Build and install the guest kernel from [[#Git trees| the Git trees section]]<br /> <br /> Then start qemu with:<br /> <br /> &lt;nowiki&gt; # qemu [...] -device virtio-balloon,automatic=true&lt;/nowiki&gt;<br /> <br /> To see automatic ballooning in action, do the following:<br /> <br /> # Generate pressure in your host (like running several VMs in parallel); or connect to QMP and issue the ''balloon-inject-host-pressure'' command<br /> # You can monitor automatic ballooning activity by issuing ''info balloon'' in QEMU's monitor (also, I have debug code enabled that will dump a lot of info to stdout when &quot;info balloon&quot; is issued)<br /> # After the guest has shrinked a bit, you can generate pressure in the guest to see it increasing its size again</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=5018 2014-01-16T20:44:24Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> The balloon feature allows KVM guests to reduce their memory size (thus relinquishing memory to the host) and to increase back (thus taking memory from the host).<br /> <br /> This feature is mainly intended to support memory over-committed hosts. That is, hosts that are running VMs whose total memory size is greater than what the host has physically available. For example, a 2G host running two VMs each with 2G would be over-committed.<br /> <br /> The balloon feature is important to support memory over-commitment because it allows for reducing a guest's memory size if needed. Suppose, in the example above, that one of the guests is using 1G and its other 1G is free. We could use the balloon to reduce this guest's size from 2G to 1G, this would free 1G in the host allowing the other VM to use it. Of course, if the reduced guest wants to run an application that consumes more than the 1G it currently has, it has to grow again.<br /> <br /> That's the problem with the current balloon feature, it's entirely manual. Someone (or some tool) is supposed to be watching the pressure in the host and guest and then operate the balloon accordingly. This is just not doable in practice.<br /> <br /> The balloon has to be automatic in order to be really useful. It could like this: when the host is under pressure, VMs with spare memory automatically reduce their size by some megas. When a VM get into memory pressure (maybe because they relinquished memory to host) it increases its size by some megas. That's exactly what the automatic ballooning patch series does.<br /> <br /> === KVM Forum 2013 presentation slides ===<br /> <br /> They can be found [http://www.linux-kvm.org/wiki/images/f/f6/Automatic-ballooning-slides.pdf here], but note that much has changed since this talk.<br /> <br /> == Patches and Git trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''Guest kernel:''' [http://marc.info/?l=kvm&amp;m=138988948715638&amp;w=2 RFC PATCH 0/4 virtio_balloon: add pressure notification via a new virtqueue]<br /> <br /> '''QEMU:''' [http://marc.info/?l=kvm&amp;m=138988966315690&amp;w=2 RFC PATCH balloon: add automatic ballooning support]<br /> <br /> === Git trees ===<br /> <br /> '''Guest kernel:'''<br /> <br /> [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git git://repo.or.cz/linux-2.6/luiz-linux-2.6.git] virtio-balloon/pressure-notification/rfc.v1<br /> <br /> '''QEMU:'''<br /> <br /> [http://repo.or.cz/w/qemu/qmp-unstable.git git://repo.or.cz/qemu/qmp-unstable.git] balloon-automatic/handle-all-events/rfc.v1<br /> <br /> == Testing ==<br /> <br /> Setup:<br /> <br /> # Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled<br /> # Build QEMU from [[#Git trees| the Git trees section]]<br /> # Build and install the guest kernel from [[#Git trees| the Git trees section]]<br /> <br /> Then start qemu with:<br /> <br /> &lt;nowiki&gt; # qemu [...] -device virtio-balloon,automatic=true&lt;/nowiki&gt;<br /> <br /> To see automatic ballooning in action, do the following:<br /> <br /> # Generate pressure in your host (like running several VMs in parallel); or connect to QMP and issue the ''balloon-inject-host-pressure'' command<br /> # You can monitor automatic ballooning activity by issuing ''info balloon'' in QEMU's monitor (also, I have debug code enabled that will dump a lot of info to stdout when &quot;info balloon&quot; is issued)<br /> # After the guest has shrinked a bit, you can generate pressure in the guest to see it increasing its size again</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=5017 2014-01-16T20:39:10Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> The balloon feature allows KVM guests to reduce their memory size (thus relinquishing memory to the host) and to increase back (thus taking memory from the host).<br /> <br /> This feature is mainly intended to support memory over-committed hosts. That is, hosts that are running VMs whose total memory size is greater than what the host has physically available. For example, a 2G host running two VMs each with 2G would be over-committed.<br /> <br /> The balloon feature is important to support memory over-commitment because it allows for reducing a guest's memory size if needed. Suppose, in the example above, that one of the guests is using 1G and its other 1G is free. We could use the balloon to reduce this guest's size from 2G to 1G, this would free 1G in the host allowing the other VM to use it. Of course, if the reduced guest wants to run an application that consumes more than the 1G it currently has, it has to grow again.<br /> <br /> That's the problem with the current balloon feature, it's entirely manual. Someone (or some tool) is supposed to be watching the pressure in the host and guest and then operate the balloon accordingly. This is just not doable in practice.<br /> <br /> The balloon has to be automatic in order to be really useful. It could like this: when the host is under pressure, VMs with spare memory automatically reduce their size by some megas. When a VM get into memory pressure (maybe because they relinquished memory to host) it increases its size by some megas. That's exactly what the automatic ballooning patch series does.<br /> <br /> === KVM Forum 2013 presentation slides ===<br /> <br /> They can be found [http://www.linux-kvm.org/wiki/images/f/f6/Automatic-ballooning-slides.pdf here]. But note that much has changed since this talk.<br /> <br /> == Patches and Git trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''Guest kernel:''' [http://marc.info/?l=kvm&amp;m=138988948715638&amp;w=2 RFC PATCH 0/4 virtio_balloon: add pressure notification via a new virtqueue]<br /> <br /> '''QEMU:''' [http://marc.info/?l=kvm&amp;m=138988966315690&amp;w=2 RFC PATCH balloon: add automatic ballooning support]<br /> <br /> === Git trees ===<br /> <br /> '''Guest kernel:'''<br /> <br /> [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git git://repo.or.cz/linux-2.6/luiz-linux-2.6.git] virtio-balloon/pressure-notification/rfc.v1<br /> <br /> '''QEMU:'''<br /> <br /> [http://repo.or.cz/w/qemu/qmp-unstable.git git://repo.or.cz/qemu/qmp-unstable.git] balloon-automatic/handle-all-events/rfc.v1<br /> <br /> == Testing ==<br /> <br /> Setup:<br /> <br /> # Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled<br /> # Build QEMU from [[#Git trees| the Git trees section]]<br /> # Build and install the guest kernel from [[#Git trees| the Git trees section]]<br /> <br /> Then start qemu with:<br /> <br /> &lt;nowiki&gt; # qemu [...] -device virtio-balloon,automatic=true&lt;/nowiki&gt;<br /> <br /> To see automatic ballooning in action, do the following:<br /> <br /> # Generate pressure in your host (like running several VMs in parallel); or connect to QMP and issue the ''balloon-inject-host-pressure'' command<br /> # You can monitor automatic ballooning activity by issuing ''info balloon'' in QEMU's monitor (also, I have debug code enabled that will dump a lot of info to stdout when &quot;info balloon&quot; is issued)<br /> # After the guest has shrinked a bit, you can generate pressure in the guest to see it increasing its size again</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=5016 2014-01-16T20:35:26Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> The balloon feature allows KVM guests to reduce their memory size (thus relinquishing memory to the host) and to increase back (thus taking memory from the host).<br /> <br /> This feature is mainly intended to support memory over-committed hosts. That is, hosts that are running VMs whose total memory size is greater than what the host has physically available. For example, a 2G host running two VMs each with 2G would be over-committed.<br /> <br /> The balloon feature is important to support memory over-commitment because it allows for reducing a guest's memory size if needed. Suppose, in the example above, that one of the guests is using 1G and its other 1G is free. We could use the balloon to reduce this guest's size from 2G to 1G, this would free 1G in the host allowing the other VM to use it. Of course, if the reduced guest wants to run an application that consumes more than the 1G it currently has, it has to grow again.<br /> <br /> That's the problem with the current balloon feature, it's entirely manual. Someone (or some tool) is supposed to be watching the pressure in the host and guest and then operate the balloon accordingly. This is just not doable in practice.<br /> <br /> The balloon has to be automatic in order to be really useful. It could like this: when the host is under pressure, VMs with spare memory automatically reduce their size by some megas. When a VM get into memory pressure (maybe because they relinquished memory to host) it increases its size by some megas. That's exactly what the automatic ballooning patch series does.<br /> <br /> === KVM Forum 2013 presentation slides ===<br /> <br /> They can be found [http://www.linux-kvm.org/wiki/images/f/f6/Automatic-ballooning-slides.pdf here]. But note that much has changed since this talk.<br /> <br /> == Patches and Git trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''Guest kernel:''' [http://marc.info/?l=kvm&amp;m=138988948715638&amp;w=2 RFC PATCH 0/4 virtio_balloon: add pressure notification via a new virtqueue]<br /> <br /> '''QEMU:''' [http://marc.info/?l=kvm&amp;m=138988966315690&amp;w=2 RFC PATCH balloon: add automatic ballooning support]<br /> <br /> === Git trees ===<br /> <br /> '''Guest kernel:'''<br /> <br /> git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/pressure-notification/rfc.v1<br /> <br /> '''QEMU:'''<br /> <br /> git://repo.or.cz/qemu/qmp-unstable.git balloon-automatic/handle-all-events/rfc.v1<br /> <br /> == Testing ==<br /> <br /> Setup:<br /> <br /> # Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled<br /> # Build QEMU from [[#Git trees| the Git trees section]]<br /> # Build and install the guest kernel from [[#Git trees| the Git trees section]]<br /> <br /> Then start qemu with:<br /> <br /> &lt;nowiki&gt; # qemu [...] -device virtio-balloon,automatic=true&lt;/nowiki&gt;<br /> <br /> To see automatic ballooning in action, do the following:<br /> <br /> # Generate pressure in your host (like running several VMs in parallel); or connect to QMP and issue the ''balloon-inject-host-pressure'' command<br /> # You can monitor automatic ballooning activity by issuing ''info balloon'' in QEMU's monitor (also, I have debug code enabled that will dump a lot of info to stdout when &quot;info balloon&quot; is issued)<br /> # After the guest has shrinked a bit, you can generate pressure in the guest to see it increasing its size again</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=5015 2014-01-16T20:31:29Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> The balloon feature allows KVM guests to reduce their memory size (thus relinquishing memory to the host) and to increase back (thus taking memory from the host).<br /> <br /> This feature is mainly intended to support memory over-committed hosts. That is, hosts that are running VMs whose total memory size is greater than what the host has physically available. For example, a 2G host running two VMs each with 2G would be over-committed.<br /> <br /> The balloon feature is important to support memory over-commitment because it allows for reducing a guest's memory size if needed. Suppose, in the example above, that one of the guests is using 1G and its other 1G is free. We could use the balloon to reduce this guest's size from 2G to 1G, this would free 1G in the host allowing the other VM to use it. Of course, if the reduced guest wants to run an application that consumes more than the 1G it currently has, it has to grow again.<br /> <br /> That's the problem with the current balloon feature, it's entirely manual. Someone (or some tool) is supposed to be watching the pressure in the host and guest and then operate the balloon accordingly. This is just not doable in practice.<br /> <br /> The balloon has to be automatic in order to be really useful. It could like this: when the host is under pressure, VMs with spare memory automatically reduce their size by some megas. When a VM get into memory pressure (maybe because they relinquished memory to host) it increases its size by some megas. That's exactly what the automatic ballooning patch series does.<br /> <br /> === KVM Forum 2013 presentation slides ===<br /> <br /> They can be found [http://www.linux-kvm.org/wiki/images/f/f6/Automatic-ballooning-slides.pdf here]. But note that much has changed since this talk.<br /> <br /> == Patches and Git trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''Guest kernel:''' [http://marc.info/?l=kvm&amp;m=138988948715638&amp;w=2 [RFC PATCH 0/4] virtio_balloon: add pressure notification via a new virtqueue]<br /> <br /> '''QEMU:''' [http://marc.info/?l=kvm&amp;m=138988966315690&amp;w=2 RFC PATCH balloon: add automatic ballooning support]<br /> <br /> === Git trees ===<br /> <br /> '''Guest kernel:'''<br /> <br /> git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/pressure-notification/rfc.v1<br /> <br /> '''QEMU:'''<br /> <br /> git://repo.or.cz/qemu/qmp-unstable.git balloon-automatic/handle-all-events/rfc.v1<br /> <br /> == Testing ==<br /> <br /> Setup:<br /> <br /> # Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled<br /> # Build QEMU from [[#Git trees| the Git trees section]]<br /> # Build and install the guest kernel from [[#Git trees| the Git trees section]]<br /> <br /> Then start qemu with:<br /> <br /> &lt;nowiki&gt; # qemu [...] -device virtio-balloon,automatic=true&lt;/nowiki&gt;<br /> <br /> To see automatic ballooning in action, do the following:<br /> <br /> # Connect to QMP and issue the balloon-inject-host-pressure command. Or,<br /> generate pressure in your host (like running several VMs in parallel)<br /> # You can monitor automatic ballooning activity by issuing &quot;info balloon&quot; in QEMU's monitor (also, I have debug code enabled that will dump a lot of info to stdout when &quot;info balloon&quot; is issued)<br /> # After guest has shrinked a bit, you can generate pressure in the guest to see it increasing its size again</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=5014 2014-01-16T20:23:30Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> The balloon feature allows KVM guests to reduce their memory size (thus relinquishing memory to the host) and to increase back (thus taking memory from the host).<br /> <br /> This feature is mainly intended to support memory over-committed hosts. That is, hosts that are running VMs whose total memory size is greater than what the host has physically available. For example, a 2G host running two VMs each with 2G would be over-committed.<br /> <br /> The balloon feature is important to support memory over-commitment because it allows for reducing a guest's memory size if needed. Suppose, in the example above, that one of the guests is using 1G and its other 1G is free. We could use the balloon to reduce this guest's size from 2G to 1G, this would free 1G in the host allowing the other VM to use it. Of course, if the reduced guest wants to run an application that consumes more than the 1G it currently has, it has to grow again.<br /> <br /> That's the problem with the current balloon feature, it's entirely manual. Someone (or some tool) is supposed to be watching the pressure in the host and guest and then operate the balloon accordingly. This is just not doable in practice.<br /> <br /> The balloon has to be automatic in order to be really useful. It could like this: when the host is under pressure, VMs with spare memory automatically reduce their size by some megas. When a VM get into memory pressure (maybe because they relinquished memory to host) it increases its size by some megas. That's exactly what the automatic ballooning patch series does.<br /> <br /> === KVM Forum 2013 presentation slides ===<br /> <br /> They can be found [http://www.linux-kvm.org/wiki/images/f/f6/Automatic-ballooning-slides.pdf here]. But note that much has changed since this talk.<br /> <br /> == Patches and Git trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''Guest kernel:''' [http://marc.info/?l=kvm&amp;m=138988948715638&amp;w=2 [RFC PATCH 0/4] virtio_balloon: add pressure notification via a new virtqueue]<br /> <br /> '''QEMU:''' [http://marc.info/?l=kvm&amp;m=138988966315690&amp;w=2 RFC PATCH balloon: add automatic ballooning support]<br /> <br /> === Git trees ===<br /> <br /> '''Guest kernel:'''<br /> <br /> git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/pressure-notification/rfc.v1<br /> <br /> '''QEMU:'''<br /> <br /> git://repo.or.cz/qemu/qmp-unstable.git balloon-automatic/handle-all-events/rfc.v1<br /> <br /> == Testing ==<br /> <br /> You have to setup the following before experimenting with auto-ballooning:<br /> <br /> # Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled<br /> # Build and install QEMU from [[#Git trees| the Git trees section]] (suggest the RFC one)<br /> # Build and install the guest kernel from [[#Git trees| the Git trees section]] (suggest the RFC one)<br /> <br /> After setting up the above, do the following to experiment with automatic deflate:<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and shrink the guest (say from 1G to 200MB)<br /> # Watch the guest increase its memory by running &quot;free&quot; within the guest (or &quot;info balloon&quot; in QEMU)<br /> <br /> There are two ways to play with automatic inflate:<br /> <br /> # The simplest thing is to create a memory constrained cgroup, but this will require code changes in QEMU because it's hardcoded to use the root cgroup (yes, we need a command-line option for that)<br /> # If you don't want to play with cgroups, you can overcommit your host by running several VMs in parallel. The VMs have to run a heavy memory workload</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=5013 2014-01-16T20:07:55Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> The balloon feature allows KVM guests to reduce their memory size (thus relinquishing memory to the host) and to increase back (thus taking memory from the host).<br /> <br /> This feature is mainly intended to support memory over-committed hosts. That is, hosts that are running VMs whose total memory size is greater than what the host has physically available. For example, a 2G host running two VMs each with 2G would be over-committed.<br /> <br /> The balloon feature is important to support memory over-commitment because it allows for reducing a guest's memory size if needed. Suppose, in the example above, that one of the guests is using 1G and its other 1G is free. We could use the balloon to reduce this guest's size to 1G, this would free 1G in the host allowing the other VM to use it. Of course, if the reduced guest wants to run an application that consumes more than the 1G it currently has, it has to grow again.<br /> <br /> That's the problem with the current balloon feature, it's entirely manual. Someone (or some tool) is supposed to be watching the pressure in the host and guest and then operate the balloon accordingly. This is just not doable in practice.<br /> <br /> The balloon has to be automatic in order to be really useful. It could like this: when the host is under pressure, VMs with spare memory automatically reduce their size by some megas. When a VM get into pressure (maybe because they relinquished memory to host) it increases its size by some megas. That's exactly what the automatic ballooning feature does.<br /> <br /> == Design ==<br /> <br /> 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:<br /> <br /> * Inflate: memory is taken from the guest and given to the host (guest shrinks)<br /> * Deflate: memory is returned from the host to the guest (guest grows)<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === KVM Forum 2013 presentation slides ===<br /> <br /> They can be found [http://www.linux-kvm.org/wiki/images/f/f6/Automatic-ballooning-slides.pdf here]<br /> <br /> === Automatic Inflate ===<br /> <br /> Automatic inflate is performed by QEMU (ie. the KVM host). QEMU registers for [http://lwn.net/Articles/544652/ memory pressure] events so that it's notified when the host is under memory pressure.<br /> <br /> 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:<br /> <br /> * 1MB on LOW pressure<br /> * 2MB on MEDIUM pressure<br /> * 4MB on CRITICAL pressure<br /> <br /> 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.<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the guest or, more specifically, by the balloon driver.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Git trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''QEMU:'''<br /> <br /> 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])<br /> <br /> '''Guest kernel:'''<br /> <br /> 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> === Development branches ===<br /> <br /> '''QEMU:'''<br /> <br /> git://repo.or.cz/qemu/qmp-unstable.git balloon/auto-ballooning/current<br /> <br /> '''Guest kernel:'''<br /> <br /> git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/auto-deflate/current<br /> <br /> == Testing ==<br /> <br /> You have to setup the following before experimenting with auto-ballooning:<br /> <br /> # Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled<br /> # Build and install QEMU from [[#Git trees| the Git trees section]] (suggest the RFC one)<br /> # Build and install the guest kernel from [[#Git trees| the Git trees section]] (suggest the RFC one)<br /> <br /> After setting up the above, do the following to experiment with automatic deflate:<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and shrink the guest (say from 1G to 200MB)<br /> # Watch the guest increase its memory by running &quot;free&quot; within the guest (or &quot;info balloon&quot; in QEMU)<br /> <br /> There are two ways to play with automatic inflate:<br /> <br /> # The simplest thing is to create a memory constrained cgroup, but this will require code changes in QEMU because it's hardcoded to use the root cgroup (yes, we need a command-line option for that)<br /> # If you don't want to play with cgroups, you can overcommit your host by running several VMs in parallel. The VMs have to run a heavy memory workload</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=5012 2014-01-16T20:00:02Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> The balloon feature allows KVM guests to reduce their memory size (thus relinquishing memory to the host) and to increase back (thus taking memory from the host).<br /> <br /> This feature is mainly intended to support memory over-committed hosts. That is, hosts that are running VMs whose the total memory is greater than what the host has physically available. For example, a host with 2G free of memory is running two VMs each with 2G would be over-committed.<br /> <br /> The balloon feature is important to support memory over-commitment because it allows for reducing a guest's memory size if needed. Suppose, in the example above, one of the guests is using 1G and its other 1G free. We could use the balloon to reduce this guest's size to 1G, this would free 1G in the host allowing the other VM to use it. Of course, if the reduced guest wants to run an application that consumes more than 1G it currently has, it has to grow again.<br /> <br /> That's the problem with the current balloon feature, it's entirely manual. Someone (or some tool) is supposed to be watching the pressure in the host and guest and then operate the balloon accordingly. This is just not doable in real life.<br /> <br /> In order to solve this problem we have to make the balloon automatic. It could like this: when the host is under pressure, VMs with spare memory automatically reduce their size by some megas. When a VM get into pressure (maybe because they relinquished memory to host) it increases its size by some megas. That's exactly what the automatic ballooning feature does.<br /> <br /> == Design ==<br /> <br /> 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:<br /> <br /> * Inflate: memory is taken from the guest and given to the host (guest shrinks)<br /> * Deflate: memory is returned from the host to the guest (guest grows)<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === KVM Forum 2013 presentation slides ===<br /> <br /> They can be found [http://www.linux-kvm.org/wiki/images/f/f6/Automatic-ballooning-slides.pdf here]<br /> <br /> === Automatic Inflate ===<br /> <br /> Automatic inflate is performed by QEMU (ie. the KVM host). QEMU registers for [http://lwn.net/Articles/544652/ memory pressure] events so that it's notified when the host is under memory pressure.<br /> <br /> 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:<br /> <br /> * 1MB on LOW pressure<br /> * 2MB on MEDIUM pressure<br /> * 4MB on CRITICAL pressure<br /> <br /> 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.<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the guest or, more specifically, by the balloon driver.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Git trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''QEMU:'''<br /> <br /> 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])<br /> <br /> '''Guest kernel:'''<br /> <br /> 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> === Development branches ===<br /> <br /> '''QEMU:'''<br /> <br /> git://repo.or.cz/qemu/qmp-unstable.git balloon/auto-ballooning/current<br /> <br /> '''Guest kernel:'''<br /> <br /> git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/auto-deflate/current<br /> <br /> == Testing ==<br /> <br /> You have to setup the following before experimenting with auto-ballooning:<br /> <br /> # Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled<br /> # Build and install QEMU from [[#Git trees| the Git trees section]] (suggest the RFC one)<br /> # Build and install the guest kernel from [[#Git trees| the Git trees section]] (suggest the RFC one)<br /> <br /> After setting up the above, do the following to experiment with automatic deflate:<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and shrink the guest (say from 1G to 200MB)<br /> # Watch the guest increase its memory by running &quot;free&quot; within the guest (or &quot;info balloon&quot; in QEMU)<br /> <br /> There are two ways to play with automatic inflate:<br /> <br /> # The simplest thing is to create a memory constrained cgroup, but this will require code changes in QEMU because it's hardcoded to use the root cgroup (yes, we need a command-line option for that)<br /> # If you don't want to play with cgroups, you can overcommit your host by running several VMs in parallel. The VMs have to run a heavy memory workload</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4982 2013-11-11T14:20:32Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> 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:<br /> <br /> * Inflate: memory is taken from the guest and given to the host (guest shrinks)<br /> * Deflate: memory is returned from the host to the guest (guest grows)<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === KVM Forum 2013 presentation slides ===<br /> <br /> They can be found [http://www.linux-kvm.org/wiki/images/f/f6/Automatic-ballooning-slides.pdf here]<br /> <br /> === Automatic Inflate ===<br /> <br /> Automatic inflate is performed by QEMU (ie. the KVM host). QEMU registers for [http://lwn.net/Articles/544652/ memory pressure] events so that it's notified when the host is under memory pressure.<br /> <br /> 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:<br /> <br /> * 1MB on LOW pressure<br /> * 2MB on MEDIUM pressure<br /> * 4MB on CRITICAL pressure<br /> <br /> 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.<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the guest or, more specifically, by the balloon driver.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Git trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''QEMU:'''<br /> <br /> 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])<br /> <br /> '''Guest kernel:'''<br /> <br /> 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> === Development branches ===<br /> <br /> '''QEMU:'''<br /> <br /> git://repo.or.cz/qemu/qmp-unstable.git balloon/auto-ballooning/current<br /> <br /> '''Guest kernel:'''<br /> <br /> git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/auto-deflate/current<br /> <br /> == Testing ==<br /> <br /> You have to setup the following before experimenting with auto-ballooning:<br /> <br /> # Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled<br /> # Build and install QEMU from [[#Git trees| the Git trees section]] (suggest the RFC one)<br /> # Build and install the guest kernel from [[#Git trees| the Git trees section]] (suggest the RFC one)<br /> <br /> After setting up the above, do the following to experiment with automatic deflate:<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and shrink the guest (say from 1G to 200MB)<br /> # Watch the guest increase its memory by running &quot;free&quot; within the guest (or &quot;info balloon&quot; in QEMU)<br /> <br /> There are two ways to play with automatic inflate:<br /> <br /> # The simplest thing is to create a memory constrained cgroup, but this will require code changes in QEMU because it's hardcoded to use the root cgroup (yes, we need a command-line option for that)<br /> # If you don't want to play with cgroups, you can overcommit your host by running several VMs in parallel. The VMs have to run a heavy memory workload</div>

LuizCapitulino https://linux-kvm.org/index.php?title=File:Automatic-ballooning-slides.pdf&diff=4981 2013-11-11T14:17:01Z

<p>LuizCapitulino: Automatic Ballooning talk slides</p> <hr /> <div>Automatic Ballooning talk slides</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4889 2013-10-10T14:08:57Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> 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:<br /> <br /> * Inflate: memory is taken from the guest and given to the host (guest shrinks)<br /> * Deflate: memory is returned from the host to the guest (guest grows)<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === Automatic Inflate ===<br /> <br /> Automatic inflate is performed by QEMU (ie. the KVM host). QEMU registers for [http://lwn.net/Articles/544652/ memory pressure] events so that it's notified when the host is under memory pressure.<br /> <br /> 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:<br /> <br /> * 1MB on LOW pressure<br /> * 2MB on MEDIUM pressure<br /> * 4MB on CRITICAL pressure<br /> <br /> 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.<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the guest or, more specifically, by the balloon driver.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Git trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''QEMU:'''<br /> <br /> 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])<br /> <br /> '''Guest kernel:'''<br /> <br /> 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> === Development branches ===<br /> <br /> '''QEMU:'''<br /> <br /> git://repo.or.cz/qemu/qmp-unstable.git balloon/auto-ballooning/current<br /> <br /> '''Guest kernel:'''<br /> <br /> git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/auto-deflate/current<br /> <br /> == Testing ==<br /> <br /> You have to setup the following before experimenting with auto-ballooning:<br /> <br /> # Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled<br /> # Build and install QEMU from [[#Git trees| the Git trees section]] (suggest the RFC one)<br /> # Build and install the guest kernel from [[#Git trees| the Git trees section]] (suggest the RFC one)<br /> <br /> After setting up the above, do the following to experiment with automatic deflate:<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and shrink the guest (say from 1G to 200MB)<br /> # Watch the guest increase its memory by running &quot;free&quot; within the guest (or &quot;info balloon&quot; in QEMU)<br /> <br /> There are two ways to play with automatic inflate:<br /> <br /> # The simplest thing is to create a memory constrained cgroup, but this will require code changes in QEMU because it's hardcoded to use the root cgroup (yes, we need a command-line option for that)<br /> # If you don't want to play with cgroups, you can overcommit your host by running several VMs in parallel. The VMs have to run a heavy memory workload</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4888 2013-10-10T14:07:20Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> 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:<br /> <br /> * Inflate: memory is taken from the guest and given to the host (guest shrinks)<br /> * Deflate: memory is returned from the host to the guest (guest grows)<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === Automatic Inflate ===<br /> <br /> Automatic inflate is performed by QEMU (ie. the KVM host). QEMU registers for [http://lwn.net/Articles/544652/ memory pressure] events so that it's notified when the host is under memory pressure.<br /> <br /> 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:<br /> <br /> * 1MB on LOW pressure<br /> * 2MB on MEDIUM pressure<br /> * 4MB on CRITICAL pressure<br /> <br /> 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.<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the guest or, more specifically, by the balloon driver.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Git trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''QEMU:'''<br /> <br /> 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])<br /> <br /> '''Guest kernel:'''<br /> <br /> 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> === Development branches ===<br /> <br /> '''QEMU:'''<br /> <br /> git://repo.or.cz/qemu/qmp-unstable.git balloon/auto-ballooning/current<br /> <br /> '''Guest kernel:'''<br /> <br /> git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/auto-deflate/current<br /> <br /> == Testing ==<br /> <br /> You have to setup the following before experimenting with auto-ballooning:<br /> <br /> # Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled<br /> # Build and install QEMU from [[#Git trees]] (suggest the RFC one)<br /> # Build and install the guest kernel from ''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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate:<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and shrink the guest (say from 1G to 200MB)<br /> # Watch the guest increase its memory by running &quot;free&quot; within the guest (or &quot;info balloon&quot; in QEMU)<br /> <br /> There are two ways to play with automatic inflate:<br /> <br /> # The simplest thing is to create a memory constrained cgroup, but this will require code changes in QEMU because it's hardcoded to use the root cgroup (yes, we need a command-line option for that)<br /> # If you don't want to play with cgroups, you can overcommit your host by running several VMs in parallel. The VMs have to run a heavy memory workload</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4887 2013-10-10T13:59:20Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> 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:<br /> <br /> * Inflate: memory is taken from the guest and given to the host (guest shrinks)<br /> * Deflate: memory is returned from the host to the guest (guest grows)<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === Automatic Inflate ===<br /> <br /> Automatic inflate is performed by QEMU (ie. the KVM host). QEMU registers for [http://lwn.net/Articles/544652/ memory pressure] events so that it's notified when the host is under memory pressure.<br /> <br /> 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:<br /> <br /> * 1MB on LOW pressure<br /> * 2MB on MEDIUM pressure<br /> * 4MB on CRITICAL pressure<br /> <br /> 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.<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the guest or, more specifically, by the balloon driver.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == GIT trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''QEMU:'''<br /> <br /> 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])<br /> <br /> '''Guest kernel:'''<br /> <br /> 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> === Development branches ===<br /> <br /> '''QEMU:'''<br /> <br /> git://repo.or.cz/qemu/qmp-unstable.git balloon/auto-ballooning/current<br /> <br /> '''Guest kernel:'''<br /> <br /> git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/auto-deflate/current<br /> <br /> == Testing ==<br /> <br /> You have to setup the following before experimenting with auto-ballooning:<br /> <br /> # Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled<br /> # Build and install 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])<br /> # Build and install the guest kernel from ''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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate:<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and shrink the guest (say from 1G to 200MB)<br /> # Watch the guest increase its memory by running &quot;free&quot; within the guest (or &quot;info balloon&quot; in QEMU)<br /> <br /> There are two ways to play with automatic inflate:<br /> <br /> # The simplest thing is to create a memory constrained cgroup, but this will require code changes in QEMU because it's hardcoded to use the root cgroup (yes, we need a command-line option for that)<br /> # If you don't want to play with cgroups, you can overcommit your host by running several VMs in parallel. The VMs have to run a heavy memory workload</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4886 2013-10-10T13:50:02Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> 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:<br /> <br /> * Inflate: memory is taken from the guest and given to the host (guest shrinks)<br /> * Deflate: memory is returned from the host to the guest (guest grows)<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === Automatic Inflate ===<br /> <br /> Automatic inflate is performed by QEMU (ie. the KVM host). QEMU registers for [http://lwn.net/Articles/544652/ memory pressure] events so that it's notified when the host is under memory pressure.<br /> <br /> 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:<br /> <br /> * 1MB on LOW pressure<br /> * 2MB on MEDIUM pressure<br /> * 4MB on CRITICAL pressure<br /> <br /> 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.<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the guest or, more specifically, by the balloon driver.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == GIT trees ==<br /> <br /> === Latest RFC version posted upstream ===<br /> <br /> '''QEMU:'''<br /> <br /> 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])<br /> <br /> '''Guest kernel:'''<br /> <br /> 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> === Development branches ===<br /> <br /> '''QEMU:'''<br /> <br /> git://repo.or.cz/qemu/qmp-unstable.git balloon/auto-ballooning/current<br /> <br /> '''Guest kernel:'''<br /> <br /> git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/auto-deflate/current<br /> <br /> == Testing ==<br /> <br /> You have to do three things to play with automatic-ballooning:<br /> <br /> # Install kernel 3.10 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG<br /> # 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])<br /> # 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and shrink guest memory (say from 1G to 200MB)<br /> # Watch the guest increase its memory by running &quot;info balloon&quot; on QEMU's monitor<br /> <br /> 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.<br /> <br /> 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.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4885 2013-10-10T13:46:02Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> 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:<br /> <br /> * Inflate: memory is taken from the guest and given to the host (guest shrinks)<br /> * Deflate: memory is returned from the host to the guest (guest grows)<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === Automatic Inflate ===<br /> <br /> Automatic inflate is performed by QEMU (ie. the KVM host). QEMU registers for [http://lwn.net/Articles/544652/ memory pressure] events so that it's notified when the host is under memory pressure.<br /> <br /> 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:<br /> <br /> * 1MB on LOW pressure<br /> * 2MB on MEDIUM pressure<br /> * 4MB on CRITICAL pressure<br /> <br /> 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.<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the guest or, more specifically, by the balloon driver.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == GIT trees ==<br /> <br /> Latest RFC version posted upstream:<br /> <br /> * QEMU: 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])<br /> * Guest kernel: 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> == Testing ==<br /> <br /> You have to do three things to play with automatic-ballooning:<br /> <br /> # Install kernel 3.10 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG<br /> # 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])<br /> # 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and shrink guest memory (say from 1G to 200MB)<br /> # Watch the guest increase its memory by running &quot;info balloon&quot; on QEMU's monitor<br /> <br /> 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.<br /> <br /> 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.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4884 2013-10-10T13:38:49Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> 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:<br /> <br /> * Inflate: memory is taken from the guest and given to the host (guest shrinks)<br /> * Deflate: memory is returned from the host to the guest (guest grows)<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === Automatic Inflate ===<br /> <br /> Automatic inflate is performed by QEMU (ie. the KVM host). QEMU registers for [http://lwn.net/Articles/544652/ memory pressure] events so that it's notified when the host is under memory pressure.<br /> <br /> 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:<br /> <br /> * 1MB on LOW pressure<br /> * 2MB on MEDIUM pressure<br /> * 4MB on CRITICAL pressure<br /> <br /> 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.<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the guest or, more specifically, by the balloon driver.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Testing ==<br /> <br /> You have to do three things to play with automatic-ballooning:<br /> <br /> # Install kernel 3.10 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG<br /> # 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])<br /> # 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and shrink guest memory (say from 1G to 200MB)<br /> # Watch the guest increase its memory by running &quot;info balloon&quot; on QEMU's monitor<br /> <br /> 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.<br /> <br /> 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.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4883 2013-10-10T13:30:51Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> 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:<br /> <br /> * Inflate: memory is taken from the guest and given to the host (guest shrinks)<br /> * Deflate: memory is returned from the host to the guest (guest grows)<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === Automatic Inflate ===<br /> <br /> Automatic inflate is performed by QEMU (ie. the KVM host). QEMU registers for [http://lwn.net/Articles/544652/ memory pressure] events so that it's notified when the host is under memory pressure.<br /> <br /> 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:<br /> <br /> * 1MB on LOW pressure<br /> * 2MB on MEDIUM pressure<br /> * 4MB on CRITICAL pressure<br /> <br /> 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.<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the guest or, more specifically, by the balloon driver.<br /> <br /> 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. The balloon driver shrink callback performs deflate by the number of pages specified by the kernel.<br /> <br /> 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 current 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. This causes the guest to grow by taking memory back from the host.<br /> <br /> == Testing ==<br /> <br /> You have to do three things to play with automatic-ballooning:<br /> <br /> # Install kernel 3.10 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG<br /> # 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])<br /> # 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and shrink guest memory (say from 1G to 200MB)<br /> # Watch the guest increase its memory by running &quot;info balloon&quot; on QEMU's monitor<br /> <br /> 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.<br /> <br /> 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.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4882 2013-10-10T13:23:37Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> 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:<br /> <br /> * Inflate: memory is taken from the guest and given to the host (guest shrinks)<br /> * Deflate: memory is returned from the host to the guest (guest grows)<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === Automatic Inflate ===<br /> <br /> Automatic inflate is performed by QEMU (ie. the KVM host). QEMU registers for [http://lwn.net/Articles/544652/ memory pressure] events so that it's notified when the host is under memory pressure.<br /> <br /> 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:<br /> <br /> * 1MB on LOW pressure<br /> * 2MB on MEDIUM pressure<br /> * 4MB on CRITICAL pressure<br /> <br /> 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.<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver within the guest. There's also two ways of implementing this:<br /> <br /> # 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<br /> # 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)<br /> <br /> == Testing ==<br /> <br /> You have to do three things to play with automatic-ballooning:<br /> <br /> # Install kernel 3.10 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG<br /> # 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])<br /> # 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and shrink guest memory (say from 1G to 200MB)<br /> # Watch the guest increase its memory by running &quot;info balloon&quot; on QEMU's monitor<br /> <br /> 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.<br /> <br /> 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.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4881 2013-10-10T13:08:21Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> 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:<br /> <br /> * Inflate: memory is taken from the guest and given to the host (guest shrinks)<br /> * Deflate: memory is returned from the host to the guest (guest grows)<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === Automatic Inflate ===<br /> <br /> 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 so that it's notified when the host is under memory pressure:<br /> <br /> # 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<br /> # 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<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver within the guest. There's also two ways of implementing this:<br /> <br /> # 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<br /> # 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)<br /> <br /> == Testing ==<br /> <br /> You have to do three things to play with automatic-ballooning:<br /> <br /> # Install kernel 3.10 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG<br /> # 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])<br /> # 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and shrink guest memory (say from 1G to 200MB)<br /> # Watch the guest increase its memory by running &quot;info balloon&quot; on QEMU's monitor<br /> <br /> 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.<br /> <br /> 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.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4842 2013-07-16T17:53:55Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> To help avoiding this scenario, 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.<br /> <br /> == Design ==<br /> <br /> KVM guests have a driver called the balloon driver. This driver allows guests to shrink and increase their memory. The balloon driver supports two operations:<br /> <br /> * Inflate: guest memory shrinks and memory is returned to the host<br /> * Deflate: guest memory increases and memory is taken from the host<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === Automatic Inflate ===<br /> <br /> 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 so that it's notified when the host is under memory pressure:<br /> <br /> # 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<br /> # 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<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver within the guest. There's also two ways of implementing this:<br /> <br /> # 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<br /> # 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)<br /> <br /> == Testing ==<br /> <br /> You have to do three things to play with automatic-ballooning:<br /> <br /> # Install kernel 3.10 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG<br /> # 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])<br /> # 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 [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and shrink guest memory (say from 1G to 200MB)<br /> # Watch the guest increase its memory by running &quot;info balloon&quot; on QEMU's monitor<br /> <br /> 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.<br /> <br /> 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.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4841 2013-07-16T17:45:46Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> To help avoiding this scenario, 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.<br /> <br /> == Design ==<br /> <br /> KVM guests have a driver called the balloon driver. This driver allows guests to shrink and increase their memory. The balloon driver supports two operations:<br /> <br /> * Inflate: guest memory shrinks and memory is returned to the host<br /> * Deflate: guest memory increases and memory is taken from the host<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === Automatic Inflate ===<br /> <br /> 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 so that it's notified when the host is under memory pressure:<br /> <br /> # 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<br /> # 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<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver within the guest. There's also two ways of implementing this:<br /> <br /> # 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<br /> # 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)<br /> <br /> == Testing ==<br /> <br /> You have to do three things to play with automatic-ballooning:<br /> <br /> # Install kernel 3.10-rc1 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG<br /> # 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])<br /> # 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])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and decrease guest memory (say from 1G to 200MB)<br /> # Watch the guest increase its memory by repeatedly running &quot;info balloon&quot; on QEMU's monitor<br /> <br /> 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.<br /> <br /> 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.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4840 2013-07-16T17:34:31Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> To help avoiding this scenario, 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.<br /> <br /> == Design ==<br /> <br /> KVM guests have a driver called the balloon driver. This driver allows guests to shrink and increase their memory. The balloon driver supports two operations:<br /> <br /> * Inflate: guest memory shrinks and memory is returned to the host<br /> * Deflate: guest memory increases and memory is taken from the host<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === Automatic Inflate ===<br /> <br /> 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:<br /> <br /> # 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<br /> # 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<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver within the guest. There's also two ways of implementing this:<br /> <br /> # 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<br /> # 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)<br /> <br /> == Testing ==<br /> <br /> You have to do three things to play with automatic-ballooning:<br /> <br /> # Install kernel 3.10-rc1 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG<br /> # 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])<br /> # 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])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and decrease guest memory (say from 1G to 200MB)<br /> # Watch the guest increase its memory by repeatedly running &quot;info balloon&quot; on QEMU's monitor<br /> <br /> 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.<br /> <br /> 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.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4839 2013-07-16T17:30:36Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> To help avoiding this scenario, 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.<br /> <br /> That's what the automatic ballooning project is about.<br /> <br /> == Design ==<br /> <br /> KVM guests have a driver called the balloon driver. This driver allows guests to shrink and increase their memory. The balloon driver supports two operations:<br /> <br /> * Inflate: guest memory shrinks and guest memory is returned to the host<br /> * Deflate: guest memory increases and memory is taken from the host<br /> <br /> Today, both operations are manual. The automatic ballooning project is about making them completely automatic, based on host and guest needs.<br /> <br /> === Automatic Inflate ===<br /> <br /> 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:<br /> <br /> # 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<br /> # 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<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver within the guest. There's also two ways of implementing this:<br /> <br /> # 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<br /> # 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)<br /> <br /> == Testing ==<br /> <br /> You have to do three things to play with automatic-ballooning:<br /> <br /> # Install kernel 3.10-rc1 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG<br /> # 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])<br /> # 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])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and decrease guest memory (say from 1G to 200MB)<br /> # Watch the guest increase its memory by repeatedly running &quot;info balloon&quot; on QEMU's monitor<br /> <br /> 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.<br /> <br /> 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.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4826 2013-06-17T21:09:58Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> === Automatic Inflate ===<br /> <br /> 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:<br /> <br /> # 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<br /> # 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<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver within the guest. There's also two ways of implementing this:<br /> <br /> # 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<br /> # 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)<br /> <br /> == Testing ==<br /> <br /> You have to do three things to play with automatic-ballooning:<br /> <br /> # Install kernel 3.10-rc1 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG<br /> # 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])<br /> # 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])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and decrease guest memory (say from 1G to 200MB)<br /> # Watch the guest increase its memory by repeatedly running &quot;info balloon&quot; on QEMU's monitor<br /> <br /> 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.<br /> <br /> 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.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4825 2013-06-17T20:51:41Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> === Automatic Inflate ===<br /> <br /> 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:<br /> <br /> # 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<br /> # 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<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver within the guest. There's also two ways of implementing this:<br /> <br /> # 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<br /> # 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)<br /> <br /> == Testing ==<br /> <br /> You have to do three things to play with automatic-ballooning:<br /> <br /> # Install kernel 3.10-rc1 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG<br /> # 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])<br /> # 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])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):<br /> <br /> # Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and decrease guest memory (say from 1G to 200MB)<br /> # Watch the guest increase its memory by repeatedly running &quot;info balloon&quot; on QEMU's monitor<br /> <br /> 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.<br /> <br /> 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.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4824 2013-06-17T20:49:54Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> === Automatic Inflate ===<br /> <br /> 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:<br /> <br /> # 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<br /> # 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<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver within the guest. There's also two ways of implementing this:<br /> <br /> # 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<br /> # 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)<br /> <br /> == Testing ==<br /> <br /> You have to do three things to play with automatic-ballooning:<br /> <br /> # Install kernel 3.10-rc1 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG<br /> # 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])<br /> # 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])<br /> <br /> After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):<br /> <br /> # Pass -balloon virtio,auto-balloon=true when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and decrease guest memory (say from 1G to 200MB)<br /> # Watch the guest increase its memory by repeatedly running &quot;info balloon&quot; on QEMU's monitor<br /> <br /> 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.<br /> <br /> 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.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4823 2013-06-17T20:40:45Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> === Automatic Inflate ===<br /> <br /> 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:<br /> <br /> # 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<br /> # 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<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver within the guest. There's also two ways of implementing this:<br /> <br /> # 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<br /> # 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)<br /> <br /> == Testing ==<br /> <br /> You have to do three things to play with automatic-ballooning:<br /> <br /> # Build &amp; install kernel 3.10-rc1 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG<br /> # 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])<br /> # Build &amp; 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])<br /> <br /> After setting up the above, do the following to actually try automatic ballooning:<br /> <br /> # Pass -balloon virtio,auto-balloon=true when starting QEMU<br /> # Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)<br /> # Switch to QEMU's monitor and decrease guest memory (say from 1G to 200MB)<br /> # Watch the guest to increase its memory by repeatedly running &quot;info balloon&quot; on QEMU's monitor</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4822 2013-06-17T20:01:05Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> === Automatic Inflate ===<br /> <br /> 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:<br /> <br /> # 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<br /> # 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<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver within the guest. There's also two ways of implementing this:<br /> <br /> # 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<br /> # 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)<br /> <br /> == Testing ==</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4810 2013-06-13T21:11:26Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> === Automatic Inflate ===<br /> <br /> 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:<br /> <br /> # 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<br /> # 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<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver in the guest. There's also two ways of implementing this:<br /> <br /> # 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<br /> # 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)<br /> <br /> == Testing ==</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4809 2013-06-13T21:05:48Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> === Automatic Inflate ===<br /> <br /> 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:<br /> <br /> # QEMU registers for VMPRESSURE_MEDIUM event and inflates the balloon by an user specified value when that event is received. That value value could default to 16MB or 32MB. This is what the current patchset does<br /> # QEMU registers for the three memory pressure events and inflates the balloon accordingly. Say, it inflates 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<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver in the guest. There's also two ways of implementing this:<br /> <br /> # 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<br /> # 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 used in automatic inflate)<br /> <br /> == Testing ==</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4808 2013-06-13T21:05:21Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> === Automatic Inflate ===<br /> <br /> 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:<br /> <br /> # QEMU registers for VMPRESSURE_MEDIUM event and inflates the balloon by an user specified value when that event is received. That value value could default to 16MB or 32MB. This is what the current patchset does<br /> <br /> # QEMU registers for the three memory pressure events and inflates the balloon accordingly. Say, it inflates 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<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver in the guest. There's also two ways of implementing this:<br /> <br /> # 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<br /> <br /> # 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 used in automatic inflate)<br /> <br /> == Testing ==</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4807 2013-06-13T20:56:56Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> === Automatic Inflate ===<br /> <br /> Automatic inflate is done 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:<br /> <br /> * QEMU registers for VMPRESSURE_MEDIUM and inflates the balloon by an user specified amount, which could default to 16MB or 32MB. This is what the current patchset does<br /> <br /> * QEMU registers for the three memory pressure events and inflates the balloon accordingly, say it inflates 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 on the vmpressure code which doesn't allow this. I'll fix it<br /> <br /> === Automatic Deflate ===<br /> <br /> Automatic deflate is performed by the virtio-balloon driver in the guest. There's also two ways of implementing this:<br /> <br /> * 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 code does<br /> <br /> * The virtio-balloon driver registers for an in-kernel vmpressure event (not upstream yet) and deflates the balloon by some fixed amount (maybe the same used in automatic inflate)<br /> <br /> == Testing ==</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4806 2013-06-13T20:49:34Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Design ==<br /> <br /> === Automatic Inflate ===<br /> <br /> Automatic inflate is done 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:<br /> <br /> * QEMU registers for VMPRESSURE_MEDIUM and inflates the balloon by an user specified amount, which could default to 16MB or 32MB. This is what the current patchset does<br /> <br /> * QEMU registers for the three memory pressure events and inflates the balloon accordingly, say it inflates 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 on the vmpressure code which doesn't allow this. I'll fix it</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4805 2013-06-13T20:20:18Z

<p>LuizCapitulino: </p> <hr /> <div>= Automatic Ballooning =<br /> <br /> == Introduction ==<br /> <br /> 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).<br /> <br /> 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).<br /> <br /> === status ===<br /> <br /> '''FIXME''': add tree.<br /> <br /> === testing ===<br /> <br /> '''FIXME''': describe.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4614 2012-12-12T14:05:56Z

<p>LuizCapitulino: </p> <hr /> <div>= Auto-ballooning =<br /> <br /> 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).<br /> <br /> 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).<br /> <br /> The goal of this page is to collect ideas on how to implement auto-ballooning.<br /> Currently, there is only one proposal, which is the &quot;automatic balance&quot; idea,<br /> mostly designed by Rik van Riel.<br /> <br /> == Automatic balance ==<br /> <br /> 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.<br /> <br /> It's expected that inflate and deflate will balance each other over time.<br /> <br /> Next sections describe the implementation details of this idea.<br /> <br /> === auto-inflate ===<br /> <br /> There are two components needed to make auto-inflate work.<br /> <br /> * A (host) kernel API to let user-space processes know when the kernel is facing memory pressure<br /> <br /> * QEMU changes to use the host kernel API, and to inflate the guest's balloon when the host kernel is facing memory pressure<br /> <br /> === auto-deflate ===<br /> <br /> Only one component is needed for auto-deflate<br /> <br /> * The guest virtio-balloon driver must be changed to automatically deflate the balloon when the guest is facing memory pressure<br /> <br /> === status ===<br /> <br /> '''FIXME''': add tree.<br /> <br /> === testing ===<br /> <br /> '''FIXME''': describe.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4613 2012-12-12T14:03:27Z

<p>LuizCapitulino: </p> <hr /> <div>= Auto-ballooning =<br /> <br /> 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).<br /> <br /> 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).<br /> <br /> The goal of this page is to collect ideas on how to implement auto-ballooning.<br /> Currently, there is only one proposal, which is the &quot;automatic balance&quot; idea,<br /> mostly designed by Rik van Riel.<br /> <br /> == Automatic balance ==<br /> <br /> 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.<br /> <br /> It's expected that inflate and deflate will balance each other over time.<br /> <br /> Next sections describe the implementation details of this idea.<br /> <br /> === auto-inflate ===<br /> <br /> There are three components needed to make auto-inflate work.<br /> <br /> * A host kernel API to let user-space processes know when the kernel is facing memory pressure ('''TODO''': point to mempressure API)<br /> <br /> * QEMU changes to use the host kernel API, and to inflate the guest's balloon when the host kernel is facing memory pressure<br /> <br /> === auto-deflate ===<br /> <br /> Only one component is needed for auto-deflate:<br /> <br /> * The guest virtio-balloon driver must be changed to automatically deflate the balloon when the guest is facing memory pressure<br /> <br /> === status ===<br /> <br /> '''FIXME''': add tree.<br /> <br /> === testing ===<br /> <br /> '''FIXME''': describe.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4612 2012-12-12T01:45:04Z

<p>LuizCapitulino: </p> <hr /> <div>= Auto-ballooning =<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> The goal of this page is to collect ideas on how to implement auto-ballooning.<br /> Currently, there is only one proposal, which is the &quot;automatic balance&quot; idea,<br /> mostly designed by Rik van Riel.<br /> <br /> == Automatic balance ==<br /> <br /> 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).<br /> <br /> It's expected that inflate and deflate will automatically balance each other over time.<br /> <br /> Next sections describe the implementation details of this idea.<br /> <br /> === auto-inflate ===<br /> <br /> There are three components needed to make auto-inflate work.<br /> <br /> * A host kernel API to let user-space processes know when the kernel is facing memory pressure ('''TODO''': point to mempressure API)<br /> <br /> * QEMU changes to use the host kernel API, and to inflate the guest's balloon when the host kernel is facing memory pressure<br /> <br /> === auto-deflate ===<br /> <br /> Only one component is needed for auto-deflate:<br /> <br /> * The guest virtio-balloon driver must be changed to automatically deflate the balloon when the guest is facing memory pressure<br /> <br /> === status ===<br /> <br /> '''FIXME''': add tree.<br /> <br /> === testing ===<br /> <br /> '''FIXME''': describe.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4611 2012-12-12T01:43:38Z

<p>LuizCapitulino: </p> <hr /> <div>= Auto-ballooning =<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> The goal of this page is to collect ideas on how to implement auto-ballooning.<br /> Currently, there is only one proposal, which is the &quot;automatic balance&quot; idea,<br /> mostly designed by Rik van Riel.<br /> <br /> == Automatic balance ==<br /> <br /> 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).<br /> <br /> It's expected that inflate and deflate will automatically balance each other over time.<br /> <br /> Next sections describe the implementation details of this idea.<br /> <br /> === auto-inflate ===<br /> <br /> There are three components needed to make auto-inflate work.<br /> <br /> * A host kernel API to let user-space processes know when the kernel is facing memory pressure ('''TODO''': point to mempressure API)<br /> <br /> * QEMU changes to use the host kernel API, and to inflate the guest's balloon when the host kernel is facing memory pressure<br /> <br /> === auto-deflate ===<br /> <br /> Only one component is needed for auto-deflate:<br /> <br /> * The guest virtio-balloon driver must be changed to automatically deflate the balloon when the guest is facing memory pressure<br /> <br /> === status ===<br /> <br /> '''FIXME''': add tree.<br /> <br /> === Testing ===<br /> <br /> '''FIXME''': add tree.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4610 2012-12-12T01:42:01Z

<p>LuizCapitulino: </p> <hr /> <div>= Auto-ballooning =<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> The goal of this page is to collect ideas on how to implement auto-ballooning.<br /> Currently, there is only one proposal, which is the &quot;automatic balance&quot; idea,<br /> mostly designed by Rik van Riel.<br /> <br /> == Automatic balance ==<br /> <br /> 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).<br /> <br /> It's expected that inflate and deflate will automatically balance each other over time.<br /> <br /> Next sections describe the implementation details of this idea.<br /> <br /> === auto-inflate ===<br /> <br /> There are three components needed to make auto-inflate work.<br /> <br /> * A host kernel API to let user-space processes know when the kernel is facing memory pressure (TODO: point to mempressure API)<br /> <br /> * QEMU changes to use the host kernel API, and to inflate the guest's balloon when the host kernel is facing memory pressure<br /> <br /> === auto-deflate ===<br /> <br /> Only one component is needed for auto-deflate:<br /> <br /> * The guest virtio-balloon driver must be changed to automatically deflate the balloon when the guest is facing memory pressure<br /> <br /> === Status ===<br /> <br /> FIXME: add luiz tree.</div>

LuizCapitulino https://linux-kvm.org/index.php?title=Projects/auto-ballooning&diff=4609 2012-12-12T01:37:44Z

<p>LuizCapitulino: </p> <hr /> <div>= Auto-ballooning =<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> The object of this page is to collect ideas on how to implement auto-ballooning.<br /> Currently, there is only one proposal, which is the &quot;automatic balance&quot; idea,<br /> mostly designed by Rik van Riel.<br /> <br /> == Automatic balance ==<br /> <br /> 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).<br /> <br /> It's expected that automatic inflate and deflate can balance each other.<br /> <br /> Next sections describe the implementation details of this idea.<br /> <br /> === auto-inflate ===<br /> <br /> There are three components needed to make auto-inflate work.<br /> <br /> 1. A host kernel API to let user-space processes know when the kernel is facing memory pressure<br /> <br /> 2. QEMU changes to use the host kernel API, and to inflate the guest's balloon when the host kernel is facing memory pressure<br /> <br /> === auto-deflate ===<br /> <br /> Only one component is needed for auto-deflate:<br /> <br /> 1. The guest virtio-balloon driver must be changed to automatically deflate the balloon when the guest is facing memory pressure<br /> <br /> === Status ===</div>

LuizCapitulino