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

[Ravi Jonnalagadda]

Hi Kunwu,

Thanks for looking into this.  Yes, in v3 I made the drain raise
nr_accesses once per drained sample.  My intent was that a region
receiving several samples in one interval should show a stronger signal
than a region receiving one, and it let the existing access-pattern
schemes act on the samples unchanged.

> Unlike page-table or page-fault based access checks, where an access
> report is generated from a deterministic access observation, a
> hardware-sampled report represents a statistical hardware event whose
> frequency depends on the PMU configuration.
>
> For the same workload, nr_accesses may therefore have different
> scales when monitored with different PMU sampling configurations
> (for example, PEBS at a given frequency versus IBS with a different
> sample period).

Agreed, and that made me look at where this information belongs.
DAMON's data attributes monitoring already keeps a per-probe hit count
for each region, probe_hits[], which the probe weights apply to, and a
PMU sample is exactly such a data attribute sample.

So in v4 [1] the drain no longer touches nr_accesses at all; its scale
stays with the access check primitives, independent of the PMU and its
sampling settings.  A sample instead raises the region's probe_hits[]
count, at most once per sampling interval, the same per-interval bound
a probe hit has for the samples DAMON takes itself, which keeps the
count within the samples per aggregation.  The meaning differs a little:
DAMON's own sampling tests one address per region, while a perf hit
means that at least one PMU sample landed in the region during the
interval.  To act on the samples, a context sets a probe weight, which
puts it in DAMON's data attributes-only mode, and its DAMOS schemes
select regions with probe_hits_wsum filters.

> Should we document this distinction, so that users configuring DAMOS
> schemes with nr_accesses thresholds understand that the value depends
> on the hardware sampling source?

With v4, nr_accesses thresholds no longer depend on the sampling
source.  What still does is how likely a region is to get a probe hit
in an interval, so yes, that should be documented.  I left the
documentation out of the RFC until the design settles, and will cover
it there.  Since I was already respinning for the v3 review, I folded
this into v4 so that there is a testable series before Plumbers.

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

Thanks,
Ravi