qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 0/1] balloon: add a feature bit to let Guest


From: James Bottomley
Subject: Re: [Qemu-devel] [PATCH v7 0/1] balloon: add a feature bit to let Guest OS deflate
Date: Tue, 23 Jun 2015 06:23:59 -0700

On Tue, 2015-06-23 at 07:32 +0200, Michael S. Tsirkin wrote:
> On Mon, Jun 22, 2015 at 02:09:48PM -0700, James Bottomley wrote:
> > On Mon, 2015-06-22 at 15:56 +0300, Denis V. Lunev wrote:
> > > On 15/06/15 13:52, 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 to 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 (actually in
> > > > linux-next at the moment)
> > > >
> > > >    commit 5a10b7dbf904bfe01bb9fcc6298f7df09eed77d5
> > > >    Author: Raushaniya Maksudova <address@hidden>
> > > >    Date:   Mon Nov 10 09:36:29 2014 +1030
> > > >
> > > > This patch adds respective control bits into QEMU. It introduces
> > > > deflate-on-oom option for baloon device which do the trick.
> > > >
> > > > Changes from v6:
> > > > - ported to virtio_add_feature
> > > >
> > > > Changes from v5:
> > > > - ported to QEMU current
> > > >
> > > > Changes from v4:
> > > > - spelling corrected according to suggestions from Eric Blake
> > > >
> > > > Changes from v3:
> > > > - ported to git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git 
> > > > tags/for_upstream_rebased
> > > >
> > > > Changes from v2:
> > > > - fixed mistake with bit number in virtio_balloon_get_features
> > > >
> > > > Changes from v1:
> > > > - From: in patch 1 according to the original ownership
> > > > - feature processing in patch 2 as suggested by Michael. It could be 
> > > > done
> > > >    without additional field, but this will require to move the property
> > > >    level up, i.e. to PCI & CCW level.
> > > >
> > > > Signed-off-by: Raushaniya Maksudova <address@hidden>
> > > > Signed-off-by: Denis V. Lunev <address@hidden>
> > > > CC: Anthony Liguori <address@hidden>
> > > > CC: Michael S. Tsirkin <address@hidden>
> > > >
> > > > P.S. Sorry for resend (if you have caught additional patch), I have
> > > >       expirienced some troubles in the process
> > > >
> > > ping
> > 
> > We seem to have become bogged down in a dispute over whether this flag
> > should be automatically enabled or disabled.  To be honest, we don't
> > care, since we're going to be shipping qemu configured according to our
> > requirements (as are most other distros anyway).
> > 
> > However, for the sake of getting the patch in, what about putting it in
> > as is (default disable) because that has no impact to the status quo.
> > If it later turns out everyone ships in a default enabled configuration,
> > why then someone can patch upstream qemu to match.
> > 
> > James
> > 
> 
> Great, so I get your ack on it?

Sure, but I wasn't aware you were waiting for it

Acked-by: James Bottomley <address@hidden>

James





reply via email to

[Prev in Thread] Current Thread [Next in Thread]