Re: [RFC PATCH v2 0/8] mm: Hot page tracking and promotion infrastructure

[Gregory Price <gourry@gourry.net>]

On Thu, Sep 25, 2025 at 06:23:08PM +0100, Jonathan Cameron wrote:
> On Thu, 25 Sep 2025 12:06:28 -0400
> Gregory Price <gourry@gourry.net> wrote:
> 
> > It feels much more natural to put this as a zswap/zram backend.
> > 
> Agreed.  I currently see two paths that are generic (ish).
> 
> 1. zswap route - faulting as you describe on writes.

aaaaaaaaaaaaaaaaaaaaaaah but therein lies the rub

The interposition point for zswap/zram is the PTE present bit being 
hacked off to generate access faults.

If you want any random VMA to be eligible for demotion into the
tier, then you need to override that VMA's fault/protect hooks in its
vm_area_struct.  This is idea is a non-starter.

What you'd have to do is have those particular vm_area_struct's be
provided by some special allocator that says the memory is eligible for
demotion to compressed memory, and to route all faults through it.

That looks a lot like hacking up mm internals to support a single
hardware case.  Hard to justify.

This may quite literally only be possible to do for for unmapped pages,
which would limit the application to things like mm/filemap.c and making
IO (read/write) calls faster.

which - hey - maybe that's the best use-case anyway.  Have all the
read-only compressible filecache you want.  At least you avoid touching
disk.

~Gregory