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

[Jonathan Cameron <jonathan.cameron@huawei.com>]

On Thu, 25 Sep 2025 12:06:28 -0400
Gregory Price <gourry@gourry.net> wrote:

> 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.
> 
Agreed.  I currently see two paths that are generic (ish).

1. zswap route - faulting as you describe on writes.
2. Fail safe route - Map compressible memory it into a VM (or application)
   you don't mind killing if we loose that promotion race due to
   pathological application.  The attacker only disturbs memory allocated
   to that application / VM so the blast radius is contained.

Jonathan

> ~Gregory