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

[Davidlohr Bueso]

On Fri, 25 Sep 2026, SJ Park wrote:

> Hello Davidlohr,
>
> On Thu, 24 Sep 2026 19:12:26 -0700 Davidlohr Bueso <dave@xxxxxxxxxxxx> wrote:
> [...]
> > So perhaps any mm interface for this stuff should just not be designed
> > around sampling, and instead proper hardware sources?
>
> Makes sense to me.  I proposed [1] damos_add_folios() in LSFMMBPF'25 for a
> reason that is similar to your points in my humble view.  To quote from the
> slide [2],
>
>    +/**
>    + * damos_add_folios - Add a list of folios as highest priority target for given
>    + *                    damos.
>    + * @scheme:    DAMOS scheme for the specific access-aware operation.
>    + * @folios:    List of folios to apply the access-aware operation.
>    + *
>    + * If a kernel component finds folios that eligible for a specific memory
>    + * management operation (e.g., CXL-promotion or demotion), execution of the
>    + * operation can be requested to be done by DAMOS using this function.  The
>    + * execution of the operation will be asynchronously done by DAMOS worker
>    + * thread.  DAMOS features for resource control (DAMOS quotas) will also be
>    + * applied.
>    + */
>    +void damos_add_folios(struct damos *scheme, struct list_head *folios)

Considering chmu alone would not justify a generic mm interface, I am more and more
inclined to go with the chmu <-> DAMON option (I recall your presentation) + do
NUMAB async (1 and 2) and that would solve most problems in a practical manner.

Thanks,
Davidlohr