From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46275) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1yue-0005yB-DZ for qemu-devel@nongnu.org; Mon, 08 Jun 2015 11:24:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z1yuZ-00070o-FV for qemu-devel@nongnu.org; Mon, 08 Jun 2015 11:24:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1yuZ-00070P-80 for qemu-devel@nongnu.org; Mon, 08 Jun 2015 11:24:27 -0400 Date: Mon, 8 Jun 2015 17:24:23 +0200 From: "Michael S. Tsirkin" Message-ID: <20150608172414-mutt-send-email-mst@redhat.com> References: <1425020265-25939-1-git-send-email-den@openvz.org> <1425020265-25939-3-git-send-email-den@openvz.org> <1427881468.3559.33.camel@HansenPartnership.com> <20150401114802-mutt-send-email-mst@redhat.com> <1427881902.3559.34.camel@HansenPartnership.com> <20150401121225-mutt-send-email-mst@redhat.com> <5547403A.5000506@openvz.org> <1433775282.2291.7.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1433775282.2291.7.camel@HansenPartnership.com> Subject: Re: [Qemu-devel] [PATCH 2/2] balloon: add a feature bit to let Guest OS deflate balloon on oom List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: James Bottomley Cc: "Denis V. Lunev" , qemu-devel@nongnu.org, Raushaniya Maksudova , Anthony Liguori On Mon, Jun 08, 2015 at 07:54:42AM -0700, James Bottomley wrote: > 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 > > >>>>> 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 > Yes, please do.