From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Mike Kaplinskiy <mike@recall.ai>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, liam@infradead.org, david@kernel.org,
vbabka@kernel.org, jannh@google.com
Subject: Re: [BUG/RFC] mm/madvise: MADV_WILLNEED skips swapped file-backed COW pages
Date: Thu, 3 Sep 2026 20:03:00 +0100 [thread overview]
Message-ID: <apm68kgHC0NK2zVI@gremlin> (raw)
In-Reply-To: <CABeknB_S2XJSHFgnHdgnN0rjzHhH4oQJs_APq9fvxHztQ_pgiA@mail.gmail.com>
On Mon, Aug 31, 2026 at 11:24:48AM -0700, Mike Kaplinskiy wrote:
> Hi,
>
> I'm seeing a strange behavior when using MADV_WILLNEED to schedule
> swap page-in. It seems MADV_WILLNEED does not schedule swap reads for
> swapped-out COW pages in an ordinary file-backed MAP_PRIVATE mapping.
>
> I reproduced this on Linux 7.0.14 on aarch64, but I think this code
> hasn't changed in a while. mm/madvise.c:madvise_willneed walks swap
It's more a known limitation of MADV_WILLNEED that has existed forever.
The issue is that every single MAP_PRIVATE-file backed mapping would then
need to be walked twice, once via page tables -> swap cache and once via
readahead.
But you could figure out if it was CoW'd...
Something like:
diff --git a/mm/madvise.c b/mm/madvise.c
index bc6a7dc73021..33ff3ba69c7f 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))
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)) {
(This also happens to fix a bug there with MAP_PRIVATE-/dev/zero though
that'll get fixed with my upcoming series anyway :)
The vma->anon_vma check ensures CoW'd pages have actually been mapped in.
But then you'd have to do two walks for every single CoW'd MAP_PRIVATE-file
backed mapping.
The majority of the anon walk would be a no-op also.
> PTEs only when vma->vm_file is NULL, and sends other file-backed
> mappings to vfs_fadvise(POSIX_FADV_WILLNEED). This skips the case of
> MAP_PRIVATE mappings with changes, which frequently happens for
> libraries/binaries with relocations and/or writable globals.
>
> The code is at the top of
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/madvise.c#n282
That code is skipping non-swap entries for a swapped out shmem folio? I
think that's irrelevant to this.
> .
>
> Minimal reproducer attached. Would there be interest in changing this
> path to prefetch private copies in addition to the readahead?
I mean I'd like to hear from others, if OK I can send the patch above.
Are we concerned about the inefficiency of this?
Or dropping the mmap lock right after and faulting in the file-backed bits?
I guess if you're doing an MADV_WILLNEED you are fine with it taking a bit
of extra time to swap stuff in.
>
> Thanks,
> Mike
--
Cheers, Lorenzo
prev parent reply other threads:[~2026-09-03 19:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 18:24 [BUG/RFC] mm/madvise: MADV_WILLNEED skips swapped file-backed COW pages Mike Kaplinskiy
2026-09-03 7:05 ` zhaozhengzhuo
2026-09-03 17:03 ` Mike Kaplinskiy
2026-09-04 10:09 ` [RFC PATCH v1] mm/madvise: prefetch private file COW swap entries zhaozhengzhuo
2026-09-04 14:52 ` Lorenzo Stoakes (ARM)
2026-09-05 11:37 ` zhaozhengzhuo
2026-09-03 19:03 ` Lorenzo Stoakes (ARM) [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=apm68kgHC0NK2zVI@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=vbabka@kernel.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.