From: David Gibson <david@gibson.dropbear.id.au>
To: David Hildenbrand <david@redhat.com>
Cc: mst@redhat.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC 2/2] virtio-balloon: Restore MADV_WILLNEED hint on balloon deflate
Date: Wed, 6 Mar 2019 10:40:33 +1100 [thread overview]
Message-ID: <20190305234033.GC19715@umbus.fritz.box> (raw)
In-Reply-To: <00e325d4-b23c-7239-46e6-a55fd1f9d5f4@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2446 bytes --]
On Tue, Mar 05, 2019 at 03:15:38PM +0100, David Hildenbrand wrote:
> On 05.03.19 06:11, David Gibson wrote:
> > Prior to f6deb6d9 "virtio-balloon: Remove unnecessary MADV_WILLNEED on
> > deflate", the balloon device issued an madvise() MADV_WILLNEED on
> > pages removed from the balloon. That would hint to the host kernel
> > that the pages were likely to be needed by the guest in the near
> > future.
> >
> > It's unclear if this is actually valuable or not, and so f6deb6d9
> > removed this, essentially ignoring balloon deflate requests. However,
> > concerns have been raised that this might cause a performance
> > regression by causing extra latency for the guest in certain
> > configurations.
>
> I mean, it will mainly create page tables as far as I know. Any write to
> a page will have an overhead either way (COW zero page). Reads *might*
> be faster.
>
> As we are working on 4k granularity in the balloon (and doing
> MADV_DONTNEED on 4k granularity!), there will most probably be page
> tables already either way. A page table could only be zapped if all
> pages of that page table are MADV_DONTNEED'ed (or I assume never were
> touched), and I am not sure if "random MADV_DONTNEED'ing of 4k pages"
> will actually get rid of page tables (my assumption would be: only if a
> complete range is zapped at once). I haven't looked into the details,
> though (plenty of other stuff to do).
>
> I am not sure if I share the concerns. Real-time workload should never
> use the virtio-balloon in a way that anything like that would be possible.
>
> >
> > So, until we can get actual benchmark data to see if that's the case,
> > this restores (by default) the old behaviour, issuing a MADV_WILLNEED
> > when a page is removed from the balloon. A new property on the
> > balloon device "hint-on-deflate" can be set to false to remove this
> > behaviour for testing.
>
> This is certainly a good approach for you to finally be able to leave
> the ugly land of virtio-balloon :)
>
> But at least to me, this looks completely useless. I'll be happy to be
> proven wrong as always :)
Frankly, I agree. But mst was nervous about us making that change to
the balloon's previous behaviour.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2019-03-05 23:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-05 5:11 [Qemu-devel] [RFC 0/2] virtio-balloon: Some further fixes David Gibson
2019-03-05 5:11 ` [Qemu-devel] [RFC 1/2] virtio-balloon: Fix possible guest memory corruption with inflates & deflates David Gibson
2019-03-05 5:11 ` [Qemu-devel] [RFC 2/2] virtio-balloon: Restore MADV_WILLNEED hint on balloon deflate David Gibson
2019-03-05 14:15 ` David Hildenbrand
2019-03-05 16:03 ` Michael S. Tsirkin
2019-03-05 16:10 ` David Hildenbrand
2019-03-05 17:02 ` Michael S. Tsirkin
2019-03-05 23:42 ` David Gibson
2019-03-05 23:40 ` David Gibson [this message]
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=20190305234033.GC19715@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@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.