From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Pedro Falcato <pfalcato@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <liam@infradead.org>,
David Hildenbrand <david@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
Jann Horn <jannh@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Mike Kaplinskiy <mike@recall.ai>,
zhaozhengzhuo <zhaozhengzhuo@uniontech.com>
Subject: Re: [PATCH] mm/madvise: swap in CoW'd MAP_PRIVATE-file mappings on MADV_WILLNEED
Date: Fri, 4 Sep 2026 17:01:37 +0100 [thread overview]
Message-ID: <aprjOxDy3JCPb2oa@gremlin> (raw)
In-Reply-To: <apriM1q4GzAgP7JQ@pedro-suse.tail5790ac.ts.net>
On Fri, Sep 04, 2026 at 04:24:59PM +0100, Pedro Falcato wrote:
> On Fri, Sep 04, 2026 at 04:12:53PM +0100, Lorenzo Stoakes (ARM) wrote:
> > Currently MADV_WILLNEED treats file-backed and pure anonymous mappings
> > entirely separately - using POSIX_FADV_WILLNEED (equivalent of a readahead)
> > for the former and a tree walk and swap in to swap cache for the latter.
> >
> > MAP_PRIVATE-file backed mappings straddle the two and currently get treated
> > as if they were purely file-backed, meaning any swapped out private pages
> > remain swapped out.
> >
> > Resolve the issue by explicitly checking for CoW'd MAP_PRIVATE-file backed
> > mappings and performing both walks in this case.
> >
> > Since the logic checks for vma->anon_vma this means un-CoW'd
> > MAP_PRIVATE-file backed mappings retain only the single file walk.
> >
> > Reported-by: Mike Kaplinskiy <mike@recall.ai>
> > Closes: https://lore.kernel.org/all/CABeknB_S2XJSHFgnHdgnN0rjzHhH4oQJs_APq9fvxHztQ_pgiA@mail.gmail.com/
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> > ---
> > mm/madvise.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/madvise.c b/mm/madvise.c
> > index 73c2901b9adb..d0510dd49dde 100644
> > --- a/mm/madvise.c
> > +++ b/mm/madvise.c
> > @@ -297,10 +297,12 @@ static long madvise_willneed(struct madvise_behavior *madv_behavior)
> > loff_t offset;
> >
> > #ifdef CONFIG_SWAP
> > - if (!file) {
> > + if (!file || (vma_is_cow_mapping(vma) && vma->anon_vma)) {
>
> Couldn't this all be simplified to
>
> if (vma->anon_vma) {
>
> ? swapin needs anon pages to have been faulted-in. Non-cow mappings won't
> have an anon_vma, nor will fully empty anonymous VMAs (and that's fine).
> Right?
Hmm good point :)
Though the
if (!file)
return 0;
Would have to be outside of the block to avoid an anon unfaulted (nop) from
being skipped.
And it's a real improvement to have unfaulted anon skip...
But I find that version is documenting what's going on a lot less.
Since both anon and MAP_PRIVATE file-backed are CoW mappings we could just
reference that.
Andrew - could you swap the patch out in-place with below? Thanks!
Cheers, Lorenzo
----8<----
From a706374a1186b6b4409a0e760e8728bcadba0c96 Mon Sep 17 00:00:00 2001
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Date: Thu, 3 Sep 2026 20:08:39 +0100
Subject: [PATCH] mm/madvise: swap in CoW'd MAP_PRIVATE-file mappings on
MADV_WILLNEED
Currently MADV_WILLNEED treats file-backed and pure anonymous mappings
entirely separately - using POSIX_FADV_WILLNEED (equivalent of a readahead)
for the former and a tree walk and swap in to swap cache for the latter.
MAP_PRIVATE-file backed mappings straddle the two and currently get treated
as if they were purely file-backed, meaning any swapped out private pages
remain swapped out.
Resolve the issue by explicitly checking for CoW'd MAP_PRIVATE-file backed
mappings and performing both walks in this case.
Since the logic checks for vma->anon_vma this means un-CoW'd
MAP_PRIVATE-file backed mappings retain only the single file walk.
Reported-by: Mike Kaplinskiy <mike@recall.ai>
Closes: https://lore.kernel.org/all/CABeknB_S2XJSHFgnHdgnN0rjzHhH4oQJs_APq9fvxHztQ_pgiA@mail.gmail.com/
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
mm/madvise.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index 73c2901b9adb..963337f93a7a 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -297,11 +297,12 @@ static long madvise_willneed(struct madvise_behavior *madv_behavior)
loff_t offset;
#ifdef CONFIG_SWAP
- if (!file) {
+ if (vma_is_cow_mapping(vma) && vma->anon_vma) {
walk_page_range_vma(vma, start, end, &swapin_walk_ops, vma);
lru_add_drain(); /* Push any new pages onto the LRU now */
- return 0;
}
+ if (!file)
+ return 0;
if (shmem_mapping(file->f_mapping)) {
shmem_swapin_range(vma, start, end, file->f_mapping);
--
2.55.0
next prev parent reply other threads:[~2026-09-04 16:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 15:12 [PATCH] mm/madvise: swap in CoW'd MAP_PRIVATE-file mappings on MADV_WILLNEED Lorenzo Stoakes (ARM)
2026-09-04 15:24 ` Pedro Falcato
2026-09-04 16:01 ` Lorenzo Stoakes (ARM) [this message]
2026-09-06 0:17 ` Andrew Morton
2026-09-07 12:32 ` Lorenzo Stoakes (ARM)
2026-09-07 15:09 ` Vlastimil Babka (SUSE)
2026-09-07 15:27 ` Lorenzo Stoakes (ARM)
2026-09-07 11:51 ` David Hildenbrand (Arm)
2026-09-07 12:33 ` Lorenzo Stoakes (ARM)
2026-09-07 12:39 ` Pedro Falcato
2026-09-07 15:05 ` Vlastimil Babka (SUSE)
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=aprjOxDy3JCPb2oa@gremlin \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jannh@google.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike@recall.ai \
--cc=pfalcato@suse.de \
--cc=vbabka@kernel.org \
--cc=zhaozhengzhuo@uniontech.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 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.