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 <rmaksud...@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 -- MST