qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] set VIRTIO_BALLOON_F_MUST_TELL_HOST unconditionally
Date: Fri, 15 Apr 2011 12:17:49 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110411 Lightning/1.0b2 Thunderbird/3.1.9

On 04/15/2011 11:36 AM, Dave Hansen wrote:
On Fri, 2011-04-15 at 11:21 -0500, Anthony Liguori wrote:
This patch makes the "tell host first" logic the only case.  This
should make everybody happy, and reduce the amount of untested or
untestable code in the kernel.
It doesn't make me happy.
Darn.

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.

See the s390 balloon driver for an example of this.

I think 'tell host first' is the only sane way to do it.  Look at the
'tell host second code':

        release_pages_by_pfn(); // let other kernel users at the pages
        tell_host(); // tell the hypervisor they're used again

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.

Regards,

Anthony Liguori

-- Dave





reply via email to

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