Re: [PATCH 0/2] mm/damon/core: detect internal variation above max_nr_regions/2

[SeongJae Park]

On Mon, 25 May 2026 16:09:42 +0800 Jiayuan Chen <jiayuan.chen@xxxxxxxxx> wrote:

> 
> On 5/23/26 9:43 AM, SeongJae Park wrote:
> > On Fri, 22 May 2026 23:11:47 +0800 Jiayuan Chen <jiayuan.chen@xxxxxxxxx> wrote:
> >
> >> Hi, SJ
> >>
> >> On 5/22/26 10:42 AM, SeongJae Park wrote:
> >>> On Thu, 21 May 2026 23:07:11 +0800 Jiayuan Chen <jiayuan.chen@xxxxxxxxx> wrote:
> >>>
> >>>> Hi SJ,
> >>>>
> >>>> Thanks for taking a look.  Quick replies inline.
> >>>>
> >>>>
> >>>> On 5/21/26 10:30 PM, SeongJae Park wrote:
> >>>>> Hello Jiayuan,
> >>>>>
> >>>>> On Thu, 21 May 2026 12:52:22 +0800 Jiayuan Chen <jiayuan.chen@xxxxxxxxx> wrote:
> > [...]
> >>>> counter was just for convenience -- easier to cat a sysfs file than to wire
> >>>>
> >>>> up tracing.  Even the tracepoint covers it, It's cost to much for
> >>>> Grafana to just get
> >>>>
> >>>> a metrics by tracepoint.
> > Out of the scope of this patch series, but I'm interested in how you connect
> > DAMON outputs to Grafana.  I believe that could be useful for many people who
> > willing to get some fleet wide access pattern.  Maybe worthy to present to
> > wider audiences, like System monitoring microconf [1] at LPC?
> 
> Honestly it's nothing fancy -- we just export nr_regions as a Prometheus 
> metric because it's a
> 
> performance-relevant signal.
> 
> 
> Vsualizing access patterns is a real pain point.  I have a small 
> AI-written script that pulls region
> 
> data and turns it into a webpage I can open in the browser.  It's not 
> live like Grafana -- I just run it when I
> 
> want to look at the data.  I don't think Grafana has a component for 
> this kind of view anyway.

I agree it is difficult.  So, you are using DAMON for not data access pattern
obserrvability but access-aware system operations like proactive reclaim of
cold pages?

For Grafana integration, I'm trying to use idle time percentiels as the "format
for fleet-wide aggregation".  My previous talk [1] at LPC may give you more
details if you are interested in.

[...]
> > So I was thinking below as a suggestion.
> >
> > The basic idea is, choosing the number of regions to split based on the
> > remaining budget (max_nr_regions - nr_regions).  I'd prefer making this simple
> > and lightweight.  So suggesting something like below.
> >
> > void kdamond_split_regions()
> > {
> > 	static unsigned char rndseed;
> >
> > 	budget = max_nr_regions - current_nr_regions()
> > 	if (budget > max_nr_regions / 2)
> > 		split_step = 1
> > 	elif (budget > max_nr_regions / 3)
> > 		split_step = 2
> > 	...
> >
> > 	idx = rndseed++ % split_step;
> > 	for (; idx < current_nr_regions(), idx += split_step)
> > 		split_region(nth_region(idx));
> > }
> >
> > I think this might be similar to your downstream change, but what do you think,
> > Jiayuan?
> 
> 
> Yes, this is close to what we do downstream.  Roughly:
> 
>    void kdamond_split_regions()
>    {
>        budget = max_nr_regions - current_nr_regions()
>        if (budget == 0)
>            return
> 
>        split_step = current_nr_regions() / budget
> 
>        for_each_region(r)
>            if (get_random_u32_below(split_step) == 0)
>                split_region(r)
>    }
> 
> And I like your version better -- the step formula (max/budget) leaves
> a margin so it approaches max more smoothly. I'll try your approach first
> 
> and test it in our env.

Sounds good!  Please feel free to let me know if any help is needed :)

[...]

[1] https://lpc.events/event/19/contributions/2075/


Thanks,
SJ