Re: [RFC PATCH v4 1/1] mm/damon: add node_eligible_mem_bp and node_ineligible_mem_bp goal metrics

[SeongJae Park <sj@kernel.org>]

On Mon, 23 Mar 2026 12:41:42 -0700 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:

> On Sat, Mar 21, 2026 at 9:54 AM SeongJae Park <sj@kernel.org> wrote:
> >
> > On Fri, 20 Mar 2026 12:04:53 -0700 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:
> >
> > > Add new quota goal metrics for memory tiering that track scheme-eligible
> > > memory distribution across NUMA nodes:
> > >
> > > - DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP: ratio of eligible memory on a node
> > > - DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP: ratio of eligible memory NOT on
> > >   a node
> >
> > The description for the second metric should be "ratio of ineligible memory on
> > a node".
> >
> 
> Got it. Will fix the commit message.
> 
> > >
> > > These complementary metrics enable push-pull migration schemes that
> > > maintain a target memory distribution across different NUMA nodes
> > > representing different memory tiers, based on access patterns defined
> > > by each scheme.
> > >
> > > The metrics iterate scheme-eligible regions and use damon_get_folio()
> > > to determine NUMA node placement of each folio, calculating the ratio
> > > of eligible memory on the specified node versus total eligible memory.
> > >
> > > Suggested-by: SeongJae Park <sj@kernel.org>
> > > Signed-off-by: Ravi Jonnalagadda <ravis.opensrc@gmail.com>
> > > ---
> > >  include/linux/damon.h    |   6 ++
> > >  mm/damon/core.c          | 158 ++++++++++++++++++++++++++++++++++++---
> > >  mm/damon/sysfs-schemes.c |  12 +++
> > >  3 files changed, 164 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/include/linux/damon.h b/include/linux/damon.h
> > > index b1d8fd88a0fc..490918804f85 100644
> > > --- a/include/linux/damon.h
> > > +++ b/include/linux/damon.h
> > > @@ -193,6 +193,10 @@ enum damos_action {
> > >   * @DAMOS_QUOTA_NODE_MEMCG_FREE_BP:  MemFree ratio of a node for a cgroup.
> > >   * @DAMOS_QUOTA_ACTIVE_MEM_BP:               Active to total LRU memory ratio.
> > >   * @DAMOS_QUOTA_INACTIVE_MEM_BP:     Inactive to total LRU memory ratio.
> > > + * @DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP:        Scheme-eligible memory ratio of a
> > > + *                                   node.
> > > + * @DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP:      Scheme-ineligible memory ratio of a
> > > + *                                   node.
> > >   * @NR_DAMOS_QUOTA_GOAL_METRICS:     Number of DAMOS quota goal metrics.
> > >   *
> > >   * Metrics equal to larger than @NR_DAMOS_QUOTA_GOAL_METRICS are unsupported.
> > > @@ -206,6 +210,8 @@ enum damos_quota_goal_metric {
> > >       DAMOS_QUOTA_NODE_MEMCG_FREE_BP,
> > >       DAMOS_QUOTA_ACTIVE_MEM_BP,
> > >       DAMOS_QUOTA_INACTIVE_MEM_BP,
> > > +     DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP,
> > > +     DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP,
> > >       NR_DAMOS_QUOTA_GOAL_METRICS,
> > >  };
> > >
> > > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > > index b9e12865622c..3e0ac65e34a0 100644
> > > --- a/mm/damon/core.c
> > > +++ b/mm/damon/core.c
> > > @@ -17,6 +17,8 @@
> > >  #include <linux/string.h>
> > >  #include <linux/string_choices.h>
> > >
> > > +#include "ops-common.h"
> > > +
> >
> > I don't find a reason to include this, and I'd like to avoid including that in
> > core.c unless it is really necessary.  Could you please remove this?
> >
> 
> The include was added because the implementation uses damon_get_folio() to
> determine NUMA node placement of folios when iterating eligible regions.

Thank you for clarifying, Ravi.

> Would you prefer that I move the damon_get_folio() declaration to
> include/linux/damon.h, or would you suggest a different approach such as
> adding an ops callback for the node calculation?

I'd like to keep it mm/damon/ internal if possible.  Maybe adding new files,
say, mm/damon/common.{c,h} is one option.

Just keeping it as is for now with clarification comment (e.g., "including
ops-common.h for damon_get_folio()") for now, and revisiting for cleanup in
future could also be another option.

I slightly prefer the second option at the moment.

> 
> > Below looks all good for RFC level code to move on to the next stage (dropping
> > RFC tag). :)
> >
> 
> Thank you, SJ! Will send v5 with fixes once I hear back on the above.

Sounds good, looking forward to!


Thanks,
SJ

[...]