On Thu, 14 May 2026 17:44:19 -0700 SeongJae Park <[email protected]> wrote:
> Introduce a new tracepoint for exposing the per-region per-probe > positive sample count via tracefs. > > Signed-off-by: SeongJae Park <[email protected]> > --- > include/trace/events/damon.h | 38 ++++++++++++++++++++++++++++++++++++ > mm/damon/core.c | 9 +++++++++ > 2 files changed, 47 insertions(+) > > diff --git a/include/trace/events/damon.h b/include/trace/events/damon.h > index 24fc402ab3c85..ec1e317923fd3 100644 > --- a/include/trace/events/damon.h > +++ b/include/trace/events/damon.h > @@ -130,6 +130,44 @@ TRACE_EVENT(damon_monitor_intervals_tune, > TP_printk("sample_us=%lu", __entry->sample_us) > ); > > +TRACE_EVENT_CONDITION(damon_aggregated_v2, I was thinking [1] about a better name of this tracepoint. I will rename this to 'damon_region_aggregated'. And I will deprecate damon_aggregated, with multi phase, like we did for DAMON debugfs interface. The idea off the top of my head at the moment is, 1. announce it as deprecated on the document, by end of 2026 2. rename it (e.g., damon_aggregated_deprecated) by end of 2027 3. removing the code by end of 2028 The deprecation might be done faster than the current idea. As Steven commented [2], it should be ok to immediately removing it or extending it to have probe_hits. But I realize I'm quite lazy at DAMON user-space tool development, and feel more comfortable on this approach for now. Please let me know if anyone has a different opinion. [1] https://lore.kernel.org/[email protected] [2] https://lore.kernel.org/[email protected] Thanks, SJ [...]
