Re: [LSF/MM/BPF TOPIC] Per-process page size

[David Hildenbrand (Arm)]

On 2/20/26 05:49, Matthew Wilcox wrote:
> 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. 

Yes!

> And files that are mmaped are generally not written to.

Well, let's say many mmaped files are not written to. :)

> So there should not be much in the page cache for the common case.

You'd assume many files to either get mmaped or read/written, yes.

> And if no pages from the file have been mmaped yet, they cannot be pinned
> or mlocked.

Is there some other way for someone to block a page from getting evicted 
from the pagecache?

We have this memfd_pin_folios() thing, but I don't think we have 
something comparable for ordinary pagecache files.

... putting them into a pipe and never reading from the pipe maybe (I 
assume that's what splice() does, but not sure if it actually places the 
pages in there or whether it creates a copy first)?

But yes, doing the conversion on first mmap() should handle mlock+gup.

--
Cheers,

David