From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpCym-0004vq-BH for qemu-devel@nongnu.org; Mon, 04 May 2015 05:48:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YpCyj-0005dk-5F for qemu-devel@nongnu.org; Mon, 04 May 2015 05:48:00 -0400 Received: from mx2.parallels.com ([199.115.105.18]:50607) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpCyj-0005Ur-04 for qemu-devel@nongnu.org; Mon, 04 May 2015 05:47:57 -0400 Message-ID: <5547403A.5000506@openvz.org> Date: Mon, 4 May 2015 12:47:38 +0300 From: "Denis V. Lunev" MIME-Version: 1.0 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> In-Reply-To: <20150401121225-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" , James Bottomley Cc: qemu-devel@nongnu.org, Raushaniya Maksudova , Anthony Liguori 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?