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

[Gregory Price <gourry@gourry.net>]

On Thu, Sep 25, 2025 at 04:24:26PM +0100, Jonathan Cameron wrote:
> The CoW thing only works because it's a permissions fault at point of
> asking for permission to write (so way before it goes into the cache).
> Then you can check margins to make sure you can still sink all outstanding
> writes if they become uncompressible and only let the write through if safe
> - if not promote some stuff before letting it proceed.
> Or you just promote on write and rely on the demotion path performing those
> careful checks later.
>

Agreed.  The question is now whether you can actually enforce page table
bits not changing.  I think you'd need your own fault handling
infrastructure / driver for these pages.

This does smell a lot like a kernel-internal dax allocation interface.
There was a bunch of talk about virtualizing zswap backends, so that
might be a nice place to look to insert this kind of hook.

Then the device driver (which it will definitely need) would have to
field page faults accordingly.

It feels much more natural to put this as a zswap/zram backend.

~Gregory