From: David Hildenbrand <david@redhat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Pedro Falcato <pfalcato@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Suren Baghdasaryan <surenb@google.com>,
Matthew Wilcox <willy@infradead.org>,
Rik van Riel <riel@surriel.com>, Harry Yoo <harry.yoo@oracle.com>,
Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Nico Pache <npache@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Jakub Matena <matenajakub@gmail.com>,
Wei Yang <richard.weiyang@gmail.com>,
Barry Song <baohua@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/11] mm/mremap: introduce more mergeable mremap via MREMAP_RELOCATE_ANON
Date: Tue, 17 Jun 2025 13:58:59 +0200 [thread overview]
Message-ID: <f86c4211-fa9c-43a4-b60a-4fc563fd4d61@redhat.com> (raw)
In-Reply-To: <58560256-58da-4fa6-a953-d2c4695ffba8@lucifer.local>
On 17.06.25 12:57, Lorenzo Stoakes wrote:
> On Tue, Jun 17, 2025 at 10:45:53AM +0200, David Hildenbrand wrote:
>> mremap() is already an expensive operation ... so I think we need a pretty
>> convincing case to make this configurable by the user at all for each
>> individual mremap() invocation.
>
> My measurements suggest, unless you hit a very unfortunate case of -huge
> faulted in range all mapped PTE- that the work involved is not all that
> much more substantial in terms of order of magnitude than a normal mremap()
> operation.
Which means we could at least try without such a flag.
Regarding MREMAP_MUST_RELOCATE_ANON, I absolutely hate it.
I'll reply to your comment to my other mail once I get to it.
Users that really care (testing) could figure out if merging worked by
looking at /proc/. Other users ... no idea what they are even supposed
to do in that case. Not mremap()? But what is the use case ...
If the "not merged" case would be relevant, a workaround would be ...
mremapping it simply back?
So if we can, let's just try without any of these flags first.
MREMAP_MUST_RELOCATE_ANON could always be added later on top, once the
use case for it is clear. Removing it from this series would not make
this series any less valuable I think.
(and of course, doing it without any flags will make this series much
more valuable :P )
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-06-17 11:59 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 13:26 [PATCH 00/11] mm/mremap: introduce more mergeable mremap via MREMAP_RELOCATE_ANON Lorenzo Stoakes
2025-06-09 13:26 ` [PATCH 01/11] " Lorenzo Stoakes
2025-06-16 20:58 ` David Hildenbrand
2025-06-17 6:37 ` Harry Yoo
2025-06-17 9:52 ` Lorenzo Stoakes
2025-06-17 10:01 ` David Hildenbrand
2025-06-17 10:07 ` Lorenzo Stoakes
2025-06-17 12:07 ` David Hildenbrand
2025-06-17 11:15 ` Harry Yoo
2025-06-17 11:24 ` Lorenzo Stoakes
2025-06-17 11:49 ` David Hildenbrand
2025-06-17 20:09 ` Lorenzo Stoakes
2025-06-09 13:26 ` [PATCH 02/11] mm/mremap: add MREMAP_MUST_RELOCATE_ANON Lorenzo Stoakes
2025-06-09 13:26 ` [PATCH 03/11] mm/mremap: add MREMAP[_MUST]_RELOCATE_ANON support for large folios Lorenzo Stoakes
2025-06-09 13:26 ` [PATCH 04/11] tools UAPI: Update copy of linux/mman.h from the kernel sources Lorenzo Stoakes
2025-06-09 13:26 ` [PATCH 05/11] tools/testing/selftests: add sys_mremap() helper to vm_util.h Lorenzo Stoakes
2025-06-09 13:26 ` [PATCH 06/11] tools/testing/selftests: add mremap() cases that merge normally Lorenzo Stoakes
2025-06-09 13:26 ` [PATCH 07/11] tools/testing/selftests: add MREMAP_RELOCATE_ANON merge test cases Lorenzo Stoakes
2025-06-09 13:26 ` [PATCH 08/11] tools/testing/selftests: expand mremap() tests for MREMAP_RELOCATE_ANON Lorenzo Stoakes
2025-06-09 13:26 ` [PATCH 09/11] tools/testing/selftests: have CoW self test use MREMAP_RELOCATE_ANON Lorenzo Stoakes
2025-06-09 13:26 ` [PATCH 10/11] tools/testing/selftests: test relocate anon in split huge page test Lorenzo Stoakes
2025-06-09 13:26 ` [PATCH 11/11] tools/testing/selftests: add MREMAP_RELOCATE_ANON fork tests Lorenzo Stoakes
2025-06-16 20:24 ` [PATCH 00/11] mm/mremap: introduce more mergeable mremap via MREMAP_RELOCATE_ANON David Hildenbrand
2025-06-16 20:41 ` David Hildenbrand
2025-06-17 8:34 ` Pedro Falcato
2025-06-17 8:45 ` David Hildenbrand
2025-06-17 10:57 ` Lorenzo Stoakes
2025-06-17 11:58 ` David Hildenbrand [this message]
2025-06-17 12:47 ` Lorenzo Stoakes
2025-06-20 18:59 ` Pedro Falcato
2025-06-20 19:28 ` Lorenzo Stoakes
2025-06-24 9:38 ` David Hildenbrand
2025-06-24 10:19 ` Lorenzo Stoakes
2025-06-24 12:05 ` David Hildenbrand
2025-06-17 10:20 ` Lorenzo Stoakes
2025-06-17 10:50 ` Lorenzo Stoakes
2025-06-17 5:42 ` Lai, Yi
2025-06-17 6:45 ` Harry Yoo
2025-06-17 9:33 ` Lorenzo Stoakes
2025-06-25 15:44 ` Lorenzo Stoakes
2025-06-25 15:58 ` Andrew Morton
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=f86c4211-fa9c-43a4-b60a-4fc563fd4d61@redhat.com \
--to=david@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=dev.jain@arm.com \
--cc=harry.yoo@oracle.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=matenajakub@gmail.com \
--cc=npache@redhat.com \
--cc=pfalcato@suse.de \
--cc=richard.weiyang@gmail.com \
--cc=riel@surriel.com \
--cc=ryan.roberts@arm.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/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;
as well as URLs for NNTP newsgroup(s).