Re: [Qemu-devel] [PATCH] set VIRTIO_BALLOON_F_MUST_TELL_HOST unconditionally

[Anthony Liguori]

On 04/15/2011 02:15 PM, Dave Hansen wrote:
> On Fri, 2011-04-15 at 12:17 -0500, Anthony Liguori wrote:
> > On 04/15/2011 11:36 AM, Dave Hansen wrote:
> > > > Why would we do this in QEMU?  This prevents the guest from doing
> > > > ballooning reclaim during OOM.
> > > What the heck is "ballooning reclaim"?  Could you elaborate a bit on how
> > > this happens?  I think I'm missing some subtlety here.
> > If you're in OOM and you need memory, you can't ask the host for more
> > and wait for a response.  You have to reclaim it immediately.
> Why not?  The call in to the notifier chain the s390 case is
> synchronous.  The OOM only affects one task at a time and won't proceed
> elsewhere while this is going on.

Because if we tell the host, we have to wait for the host to ack which 
means we'd sleep waiting for an interrupt.  Can you do this in the OOM path?

> > > At the point we've started using the pages again, we haven't *told* the
> > > host that we're using them.  I think that's potentially a problem.  Is
> > > qemu somehow cool with the guest touching pages that are supposed to be
> > > in the balloon and unusable?
> > Yes, of course it is.  All ballooning does is madvise(MADV_DONTNEED).  A
> > guest can reclaim the memory as soon as it wants it to.
> That's not true on all hypervisors, but as long as it's a guarantee in
> qemu, I guess we're OK here.  Let's hope nobody else ever starts to use
> virtio-balloon.

If you haven't figured out yet, I'm kind of partial to a certain 
hypervisor....

That's why this option exists in the first place.  To let QEMU do it's 
thing and for other hypervisors that are not quite as clever, they could 
advertise this bit.

> Why do we even _tell_ qemu, though?  The MADV_WILLNEED is nice, but far
> from being necessary.  We could just skip the entire notification in OOM
> situations.

There's really no particular reason to other than symmetry.

Regards,

Anthony Liguori

> -- Dave