On 2/17/26 16:22, Matthew Wilcox wrote:

On Tue, Feb 17, 2026 at 08:20:26PM +0530, Dev Jain wrote:

quoted

2. Generic Linux MM enlightenment
---------------------------------
We enlighten the Linux MM code to always hand out memory in the granularity

Please don't use the term "enlighten".  Tht's used to describe something
something or other with hypervisors.  Come up with a new term or use one
that already exists.

quoted

File memory
-----------
For a growing list of compliant file systems, large folios can already be
stored in the page cache. There is even a mechanism, introduced to support
filesystems with block sizes larger than the system page size, to set a
hard-minimum size for folios on a per-address-space basis. This mechanism
will be reused and extended to service the per-process page size requirements.

One key reason that the 64K kernel currently consumes considerably more memory
than the 4K kernel is that Linux systems often have lots of small
configuration files which each require a page in the page cache. But these
small files are (likely) only used by certain processes. So, we prefer to
continue to cache those using a 4K page.
Therefore, if a process with a larger page size maps a file whose pagecache
contains smaller folios, we drop them and re-read the range with a folio
order at least that of the process order.

That's going to be messy.  I don't have a good idea for solving this
problem, but the page cache really isn't set up to change minimum folio
order while the inode is in use.

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.

-- 
Cheers,

David