Re: [RFC PATCH v3 2/9] mm/damon/core: replace the access report buffer with per-context rings

[Ravi Jonnalagadda]

>
> Hi Ravi,
>
> I noticed that ring overflow drops reports and updates an
> internal counter.
>
> Since hardware sampling is used as an access observation source,
> could userspace get any indication that reports were lost during
> an aggregation window?

Hi Kunwu,

Not in this RFC.  While developing the series, I used a developer-only
commit that exposed these counters through debugfs, purely for my own
testing; it was never meant for upstream, so the RFC keeps only the
in-kernel accessors that the kunit tests use.  v4 [1] is the same in
this respect.

> Without such visibility, users cannot distinguish an aggregation
> result affected by report loss from one collected without loss.
> This may make it difficult to evaluate the reliability of the
> observed access information.

I agree that userspace should be able to see dropped reports.  Two
things to note before exposing them: the counters are global per-CPU
counters today, not per context, so a per-context interface needs
per-context accounting first; and when perf throttles a source,
samples are lost without any drop being counted.

I see two options:

a) a read-only file under the context or probe sysfs directory, once
   the counters are per context, or
b) the drop counts through a tracepoint, per aggregation window.

Your PMU-agnostic observability series may be a natural home for (b).
What do you think?

[1] https://lore.kernel.org/all/20261005-damon-perf-rfc-v3-send-2026-10-03-v4-0-b03452e137f3@xxxxxxxxx/

Thanks,
Ravi