Re: [RFC PATCH v0] Docs/mm/damon/design: document data attributes report infra design (beyond page table accessed-bit milestone 2)

[SJ Park <sj@kernel.org>]

On Fri, 23 Oct 2026 12:51:22 -0700 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:

> Hi SJ,
> 
> On Wed, 21 Oct 2026 22:29:12 -0700 SJ Park <sj@kernel.org> wrote:
> 
> > Hi Ravi,
> >
> > On Wed, 21 Oct 2026 21:17:24 -0700 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:
> >
> [...]
> >
> > Thank you for your detailed review and testing of the first design!  I'd still
> > like to try decoding idea first, mainly for quick prototyping.
> 
> Sounds good.  Starting with decode makes sense, especially for VMs
> where hardware address-sampling PMUs are often unavailable; some tips
> for the prototype are in the other reply [1].

Thank you for confirming and the tips!

> 
> [...]
> > > Yes, if the report has an address field with a validity bit and carries
> > > the producing report-type (attr) id.  Then IBS, PEBS, Arm SPE (through
> > > an adapter, since SPE uses the perf AUX buffer) and device-side
> > > monitors all produce the same report, into the same queues and probes.
> >
> > Thank you for confirming.  And yes, I think we can add more (union) fields to
> > the report structure.
> >
> > However, could you further clarify what are the validity bit and attr id, and
> > why those are needed?  I'm still newbie to perf event, please bear in mind with
> > me.
> 
> Neither is perf-specific:
> 
> - Validity bit (or union tag): a way to tell whether a report carries a
>   virtual address, a physical address, or both.  For example, a decoded
>   sample has no physical address if the page is not mapped.  If you use
>   a union with a type field, that already covers it.

Thank you for clarifying.  Yes, it may have a union with a type field.

> 
> - Attr id: an id of the producer (report type) that made the report.  If
>   several producers later feed one queue (e.g. perf sampling and a
>   device-side monitor), a probe can filter on, or weigh, reports by
>   their source.  If each queue only ever has one producer, the queue
>   already identifies it, and the field is not needed.

Thank you for clarifying.  I agree this kind of information will be needed, and
I will make sure it is in the report struct.

> 
> [...]
> > > 4. Binary search over a sorted region snapshot (your todo in
> > >    kdamond_apply_access_report()) beats a linear walk from about 2
> > >    reports per interval for 1,000 regions (a model, to be measured).
> >
> > Yes, this efficient region-report matching would be important.  We could also
> > consider starting with linear walk and later optimize, though.
> 
> Agreed; starting with a linear walk for the prototype is fine, and once
> it is out, happy to measure where binary search starts to matter.

Cool!

> 
> [...]
> > > 5. Samplers can stop silently: in a report on the v4 thread [1], IBS
> [...]
> > Unfortunately my understanding of perf event is not yet good enough to
> > understand this in depth.  I will revisit this after starting implementation.
> 
> Sure.  The one part worth keeping in mind from the start: a sampler can
> stop without any error, so a counter of reports received and dropped
> helps tell "no accesses" from "no samples".

Good point.  I will try to make it at least easy to debug.

> 
> [...]
> > >   - The queue: the per-CPU seqcount design in note 2 (suggested), or
> > >     ftrace's ring buffer with one iterator per reader.
> >
> > My current plan is to use DAMON's original simple lockless and global queue per
> > report queue.  Let me know if the report queue design is not clearly explaining
> > what it would look like, or there is a clear problem.
> 
> A global queue is fine to start with, and the design is clear.  One
> thing to keep in mind: perf writers run in interrupt or NMI context on
> all CPUs at once, and an NMI can arrive in the middle of another write.
> So reserving a slot needs to be lock-free, and a reader should not see
> a half-written report.  If the design already covers that, there is
> nothing to add.

Design is still in progress, but definitely this should be covered.  Thank you
for calling out!

> 
> [...]
> > As soon as this design discussion is completed, I will start prototype
> > implementation and share it as the next RFC version, as soon as possible.  Your
> > review and test of the version will be super helpful.  I may also ask you some
> > questions for perf event and your prototypes.  Thanks in advance for your help.
> >
> > There are competing works, though.  It would take time.  I expect about one
> > month at minimum.  It might take longer; Thanksgiving holidays could be helpful
> > to give me a time to concentrate.  Please bear in mind.  But once the initial
> > prototype is implemented, I believe we could quickly iterate and meet the ETA
> > (LSFMMBPF'27).
> 
> No rush on the timeline; that plan sounds good.  Please feel free to
> ask any time, and I will be happy to share the test programs and review
> and test the prototype when it is out.

Appreciate your continued support, that will be super helpful!

> 
> Thanks,
> Ravi
> 
> [1] https://lore.kernel.org/r/20261023194848.2449-1-ravis.opensrc@gmail.com


Thanks,
SJ