From: Matthew Wilcox <willy@infradead.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Dev Jain <dev.jain@arm.com>,
lsf-pc@lists.linux-foundation.org, ryan.roberts@arm.com,
catalin.marinas@arm.com, will@kernel.org, ardb@kernel.org,
hughd@google.com, baolin.wang@linux.alibaba.com,
akpm@linux-foundation.org, lorenzo.stoakes@oracle.com,
Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, linux-mm@kvack.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [LSF/MM/BPF TOPIC] Per-process page size
Date: Fri, 20 Feb 2026 04:49:22 +0000 [thread overview]
Message-ID: <aZfn0tbKl_1JD-VM@casper.infradead.org> (raw)
In-Reply-To: <2e68ef61-dcf2-46b2-913f-14980a104faf@kernel.org>
On Tue, Feb 17, 2026 at 04:30:59PM +0100, David Hildenbrand (Arm) wrote:
> In a private conversation I also raised that some situations might make it
> impossible/hard to drop+re-read.
>
> One example I cam up with if a folio is simply long-term R/O pinned. But I
> am also not quite sure how mlock might interfere here.
>
> So yes, I think the page cache is likely the one of the most
> problematic/messy thing to handle.
So what if we convert to max-supported-order the first time somebody
calls mmap on a given file? Most files are never mmaped, so it won't
affect them. And files that are mmaped are generally not written to.
So there should not be much in the page cache for the common case.
And if no pages from the file have been mmaped yet, they cannot be pinned
or mlocked.
next prev parent reply other threads:[~2026-02-20 4:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-17 14:50 Dev Jain
2026-02-17 15:22 ` Matthew Wilcox
2026-02-17 15:30 ` David Hildenbrand (Arm)
2026-02-17 15:51 ` Ryan Roberts
2026-02-20 4:49 ` Matthew Wilcox [this message]
2026-02-20 16:50 ` David Hildenbrand (Arm)
2026-02-18 8:39 ` Dev Jain
2026-02-18 8:58 ` Dev Jain
2026-02-18 9:15 ` David Hildenbrand (Arm)
2026-02-20 9:49 ` Arnd Bergmann
2026-02-20 13:37 ` Pedro Falcato
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=aZfn0tbKl_1JD-VM@casper.infradead.org \
--to=willy@infradead.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=hughd@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox