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

From: KunWu Chan

Date: Tue Oct 20 2026 - 02:48:25 EST


On Mon, Oct 5, 2026 at 5:11 PM Ravi Jonnalagadda
<ravis.opensrc@xxxxxxxxx> wrote:
>
> >
> > 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?
>

Thanks, Ravi. Are you referring to my earlier
'mm/damon/perf: observability framework for hardware-sampled access reports'
series [1]?
[1] https://lore.kernel.org/all/20260818061031.827057-1-kunwu.chan@xxxxxxxxx/

I developed this framework and shared it in case it might be useful to others,
though I'm not sure whether it will eventually be merged.

The tracepoint option seems like a good fit for that work. I'll think
about it and share
any ideas I come up with.

Thanks,
Kunwu


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