From: David Hildenbrand <david@redhat.com>
To: Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>, Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"dgilbert@redhat.com" <dgilbert@redhat.com>
Subject: Re: [PATCH] mm: madvise: MADV_DONTNEED_LOCKED
Date: Fri, 4 Mar 2022 14:08:57 +0100 [thread overview]
Message-ID: <d67e9c8c-fa82-3ce4-1894-f2ad1779d834@redhat.com> (raw)
In-Reply-To: <YiE3do4qCmJ6RsmP@cmpxchg.org>
On 03.03.22 22:47, Johannes Weiner wrote:
> On Thu, Mar 03, 2022 at 04:29:56PM -0500, Johannes Weiner wrote:
>> MADV_DONTNEED historically rejects mlocked ranges, but with
>> MLOCK_ONFAULT and MCL_ONFAULT allowing to mlock without populating,
>> there are valid use cases for depopulating locked ranges as well.
Indeed, there are. I'd have use for that in QEMU for virtio-mem (which
uses MADV_POPULATE_WRITE+MADV_DONTNEED to dynamically allocate/discard
memory in a sparse memory mapping to be used by the VM, currently
doesn't support mlock for obvious reasons).
Further, QEMU postcopy live migration handling requires an munlockall()
before registering the uffd handler and discarding all RAM via
MADV_DONTNEED. Once postcopy finished, we have to mlock() again. I
didn't check if there would be more stopping uffd from working on a
mlocked region, but this would be one piece of the puzzle I guess.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2022-03-04 13:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-03 21:29 Johannes Weiner
2022-03-03 21:35 ` Nadav Amit
2022-03-03 22:25 ` Johannes Weiner
2022-03-03 21:47 ` Johannes Weiner
2022-03-04 9:12 ` Michal Hocko
2022-03-04 13:08 ` David Hildenbrand [this message]
2022-03-04 17:19 Johannes Weiner
2022-03-04 18:45 ` Mike Kravetz
2022-03-04 19:26 ` Shakeel Butt
2022-03-08 15:31 ` Vlastimil Babka
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=d67e9c8c-fa82-3ce4-1894-f2ad1779d834@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dgilbert@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=vbabka@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox