Re: [Qemu-devel] [PATCH 2/2] balloon: add a feature bit to let Guest OS deflate balloon on oom

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2015-05-04 at 12:47 +0300, Denis V. Lunev wrote:
> On 01/04/15 13:18, Michael S. Tsirkin wrote:
> > On Wed, Apr 01, 2015 at 12:51:42PM +0300, James Bottomley wrote:
> >> On Wed, 2015-04-01 at 11:50 +0200, Michael S. Tsirkin wrote:
> >>> On Wed, Apr 01, 2015 at 12:44:28PM +0300, James Bottomley wrote:
> >>>> On Fri, 2015-02-27 at 09:57 +0300, Denis V. Lunev wrote:
> >>>>> Excessive virtio_balloon inflation can cause invocation of OOM-killer,
> >>>>> when Linux is under severe memory pressure. Various mechanisms are
> >>>>> responsible for correct virtio_balloon memory management. Nevertheless it
> >>>>> is often the case that these control tools does not have enough time to
> >>>>> react on fast changing memory load. As a result OS runs out of memory and
> >>>>> invokes OOM-killer. The balancing of memory by use of the virtio balloon
> >>>>> should not cause the termination of processes while there are pages in the
> >>>>> balloon. Now there is no way for virtio balloon driver to free memory at
> >>>>> the last moment before some process get killed by OOM-killer.
> >>>>>
> >>>>> This does not provide a security breach as balloon itself is running
> >>>>> inside Guest OS and is working in the cooperation with the host. Thus
> >>>>> some improvements from Guest side should be considered as normal.
> >>>>>
> >>>>> To solve the problem, introduce a virtio_balloon callback which is
> >>>>> expected to be called from the oom notifier call chain in out_of_memory()
> >>>>> function. If virtio balloon could release some memory, it will make the
> >>>>> system return and retry the allocation that forced the out of memory
> >>>>> killer to run.
> >>>>>
> >>>>> This behavior should be enabled if and only if appropriate feature bit
> >>>>> is set on the device. It is off by default.
> >>>>>
> >>>>> This functionality was recently merged into vanilla Linux.
> >>>>>
> >>>>>    commit 5a10b7dbf904bfe01bb9fcc6298f7df09eed77d5
> >>>>>    Author: Raushaniya Maksudova <rmaksudova@parallels.com>
> >>>>>    Date:   Mon Nov 10 09:36:29 2014 +1030
> >>>>>
> >>>>> This patch adds respective control bits into QEMU. It introduces
> >>>>> deflate-on-oom option for balloon device which does the trick.
> >>>> What's the status on this, please?  It's been over a month since this
> >>>> was posted with no further review feedback, so I think it's ready.
> >>>> Getting this into qemu is blocking our next step which would be adding
> >>>> the feature bit to the virtio spec.
> >>>>
> >>>> James
> >>> This was posted after soft feature freeze for 2.3, so it'll have to go
> >>> into 2.4.  I don't see why would this block your work on the spec: you
> >>> should make progress on this meanwhile.
> >> I can do that ... I just thought the spec was trailing edge, so I was
> >> waiting to have the patch accepted, which confirms the implementation.
> >> I didn't want to write it into the spec and have the actual
> >> implementation changed by review later.
> >>
> >> James
> >>
> > It's up to you really, I would just like to point out two things:
> > - spec process is a long one, assuming we accept a spec change,
> >    we go though a public review period, multiple votes etc.
> >    About half a year to release a spec revision with
> >    new features.
> >    So time enough to make minor changes.
> > - oasis process works like this (roughly):
> > 	spec is written
> > 	spec goes through a public review process
> > 	community standard is published
> > 	3 implementations are reported
> > 	spec becomes an oasis standard
> >    so implementations aren't required at early stages
> 2.3 is done, 2.4 window is opened....
> 
> The patch is applicable for both
> git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git
> and vanilla qemu.
> 
> How can we proceed?

The spec update supporting this feature is published for review:

https://www.oasis-open.org/committees/download.php/55709/virtio-v1.0-csprd04.zip

It's probably a good idea to have the implementation there as well.  Do
we need to resend these patches?

James