Re: [RFC PATCH 0/2] damo: support perf event configuration

[SeongJae Park <sj@kernel.org>]

On Fri, 26 Jun 2026 22:56:24 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:

> 2026年6月23日(火) 22:50 SeongJae Park <sj@kernel.org>:
> >
> > On Tue, 23 Jun 2026 22:29:42 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
> >
> > > 2026年6月23日(火) 0:24 SeongJae Park <sj@kernel.org>:
> > > >
> > > > Hello Akinobu,
> > > >
> > > > On Mon, 22 Jun 2026 22:49:31 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
> > > >
> > > > > This patch set aims to make it easier to specify the perf event settings
> > > > > proposed for DAMON by Ravi's hardware-sampled access reports patch set [1]
> > > > > from the damo tool.
> > > >
> > > > Seems this patch is built on top of the per-CPU/thread/read/write monitoring
> > > > patch series [1].  We made a plan [2] to use another user interface, though.
> > > > The plan is, making the interface ready for page table accessed bits based
> > > > monitoring by LPC'26 (milestone 1), and implementing the perf event based
> > > > monitoring on top of it, by LSFMMBPF'27 (milestone 2).
> > > >
> > > > So the eventual damo part change for supporting perf event based monitoring
> > > > will be quite different from this series.  I guess you are sharing this series
> > > > not because you aiming to merge it as is right now, but just for sharing the
> > > > code with other stakeholders like Ravis, not me?  If I'm not wrong, I will skip
> > > > this series for now, to focus on the milestone 1.
> > >
> > > Since I will align with the final user interface later, please focus on
> > > the optimal interface for Milestone 1 without worrying about that.
> >
> > Thank you, Akinobu.
> >
> > >
> > > > Please let me know if you want more of my feedback.
> > >
> > > However, even if the interface ends up being completely different from the
> > > current one, I believe that enabling configuration via `damo` using
> > > symbolic event names like this would still require calling the perf
> > > python interface (`import perf`) from damo and modifying the `perf` tool
> > > itself; could you please check if that approach is acceptable?
> >
> > I'm bit concerned at having such dependencies.  I'd prefer making DAMON sysfs
> > interface uses a symbolic names and just use it from damo if possible.  If that
> > is not possible, could you share more details about why such changes are
> > required?  I'm still lazily delaying studying about perf events, so please bear
> > in mind with me.
> 
> Theoretically, it might be possible to initialize `perf_event_attr` within
> the kernel based on the symbolic names of specified PMU events.
> However, doing so would require implementing logic to read
> `/sys/bus/event_source/devices/<pmu>/format/*`, as well as duplicating
> functionality within the kernel that is currently provided by the `perf`
> user-space tools.
> 
> However, if we limit processing to only the minimal format, such as
> `pmu/config=M,config1=N,config3=K/`, described in the explanation of the
> `-e` option in `tools/perf/Documentation/perf-record.txt`, it may be
> possible to minimize duplication.

Sounds good.

I'd prefer making DAMON interface as human readable as possible, as long as it
is not duplicating things too much.

I wouldn't mind adding changes that depend on perf user-space tools or
libraries in 'damo' for making it even more human-readable, as long as it
doesn't break the backward compatibility of 'damo', and perf developers are ok
with the perf-side change.  Anyway 'damo' is using 'perf' internally ;)  And
seems perf developers are thankfully very open minded :)


Thanks,
SJ

[...]