From: Anthony Liguori <anthony@codemonkey.ws>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: Amit Shah <amit.shah@redhat.com>,
Anthony Liguori <aliguori@us.ibm.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] set VIRTIO_BALLOON_F_MUST_TELL_HOST unconditionally
Date: Fri, 15 Apr 2011 14:20:04 -0500 [thread overview]
Message-ID: <4DA89A64.7040809@codemonkey.ws> (raw)
In-Reply-To: <1302894918.16562.3880.camel@nimitz>
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
>
>
next prev parent reply other threads:[~2011-04-15 19:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-15 14:44 [Qemu-devel] [PATCH] set VIRTIO_BALLOON_F_MUST_TELL_HOST unconditionally Dave Hansen
2011-04-15 16:21 ` Anthony Liguori
2011-04-15 16:36 ` Dave Hansen
2011-04-15 17:17 ` Anthony Liguori
2011-04-15 19:15 ` Dave Hansen
2011-04-15 19:20 ` Anthony Liguori [this message]
2011-04-18 15:37 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DA89A64.7040809@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=aliguori@us.ibm.com \
--cc=amit.shah@redhat.com \
--cc=dave@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.