All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>
Cc: dhildenb@redhat.com, imammedo@redhat.com, ehabkost@redhat.com,
	pbonzini@redhat.com, qemu-devel@nongnu.org, qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [RFC 1/5] virtio-balloon: Remove unnecessary MADV_WILLNEED on deflate
Date: Mon, 15 Oct 2018 08:54:27 +0200	[thread overview]
Message-ID: <996ed901-14b6-7461-a094-771a715cd6b2@redhat.com> (raw)
In-Reply-To: <20181012140306-mutt-send-email-mst@kernel.org>

On 12/10/2018 20:05, Michael S. Tsirkin wrote:
> On Fri, Oct 12, 2018 at 02:24:27PM +1100, David Gibson wrote:
>> When the balloon is inflated, we discard memory place in it using madvise()
>> with MADV_DONTNEED.  And when we deflate it we use MADV_WILLNEED, which
>> sounds like it makes sense but is actually unnecessary.
>>
>> The misleadingly named MADV_DONTNEED just discards the memory in question,
>> it doesn't set any persistent state on it in-kernel; all that's necessary
>> to bring the memory back is to touch it.  MADV_WILLNEED in contrast
>> specifically says that the memory will be used soon and faults it in.
>>
>> Memory that's being given back to the guest by deflating the balloon
>> *might* be used soon, but it equally could just sit around in the guest's
>> pools until it actually needs it.  And, over the general timescale that
>> memory ballooning operates, it seems unlikely that one extra fault for the
>> guest will be a vast performance issue.
> 
> Thinking about it, it might be for RT guests.
> 
> So I suspect if you want to drop MADV_WILLNEED you need a flag
> telling qemu that's not the usecase.
> 

As far as I know RT guests

1. mlock all memory
2. use huge pages

"MADV_DONTNEED cannot be applied to locked pages, Huge TLB pages, or
VM_PFNMAP pages."

As DONTNEED never succeeded, WILLNEED will do nothing. (e.g. postcopy
temporarily has to unlock all memory in order to make DONTNEED work)

(And "Expect access in the near future." does not sound like guarantees
to me either way)

So I think this can go.

-- 

Thanks,

David / dhildenb

  reply	other threads:[~2018-10-15  6:54 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-12  3:24 [Qemu-devel] [RFC 0/5] Improve balloon handling of pagesizes other than 4kiB David Gibson
2018-10-12  3:24 ` [Qemu-devel] [RFC 1/5] virtio-balloon: Remove unnecessary MADV_WILLNEED on deflate David Gibson
2018-10-12  7:40   ` David Hildenbrand
2018-10-13  6:26     ` David Gibson
2018-10-12 17:41   ` Richard Henderson
2018-10-12 17:59     ` Eric Blake
2018-10-13  6:23     ` David Gibson
2018-10-12 18:05   ` Michael S. Tsirkin
2018-10-15  6:54     ` David Hildenbrand [this message]
2018-10-15 10:43       ` Michael S. Tsirkin
2018-10-15 11:14         ` David Hildenbrand
2018-12-04  4:26         ` David Gibson
2018-10-12  3:24 ` [Qemu-devel] [RFC 2/5] virtio-balloon: Corrections to address verification David Gibson
2018-10-12  7:44   ` David Hildenbrand
2018-10-13  6:25     ` David Gibson
2018-10-12  3:24 ` [Qemu-devel] [RFC 3/5] virtio-balloon: Rework ballon_page() interface David Gibson
2018-10-12  7:46   ` David Hildenbrand
2018-10-13  6:29     ` David Gibson
2018-10-12  3:24 ` [Qemu-devel] [RFC 4/5] virtio-balloon: Use ram_block_discard_range() instead of raw madvise() David Gibson
2018-10-12  3:24 ` [Qemu-devel] [RFC 5/5] virtio-balloon: Safely handle BALLOON_PAGE_SIZE < host page size David Gibson
2018-10-12  8:06   ` David Hildenbrand
2018-10-13  6:40     ` David Gibson
2018-10-15  7:08       ` David Hildenbrand
2018-10-17  3:28         ` David Gibson
2018-10-17  9:56           ` David Hildenbrand
2018-10-23  8:02             ` David Gibson
2018-10-23 15:13               ` David Hildenbrand
2018-10-12  8:32   ` David Hildenbrand
2018-10-13  6:41     ` David Gibson
2018-10-12 17:26 ` [Qemu-devel] [RFC 0/5] Improve balloon handling of pagesizes other than 4kiB Michael S. Tsirkin
2018-10-17  3:31   ` David Gibson

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=996ed901-14b6-7461-a094-771a715cd6b2@redhat.com \
    --to=david@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=dhildenb@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@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.