From: SeongJae Park <sj@kernel.org>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: SeongJae Park <sj@kernel.org>,
damon@lists.linux.dev, linux-perf-users@vger.kernel.org
Subject: Re: [RFC PATCH v3 0/4] mm/damon: introduce perf event based access check
Date: Sat, 25 Apr 2026 08:33:15 -0700 [thread overview]
Message-ID: <20260425153316.89358-1-sj@kernel.org> (raw)
In-Reply-To: <CAC5umyjcFm-iw31kgYP0Z61z7N=vMzkZKsvGZpYmNwNw3R_gHw@mail.gmail.com>
On Sat, 25 Apr 2026 21:33:07 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
> 2026年4月25日(土) 8:31 SeongJae Park <sj@kernel.org>:
> >
> > On Fri, 24 Apr 2026 12:27:07 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
> >
> > > Hello SeongJae,
> > >
> > > 2026年4月23日(木) 13:34 SeongJae Park <sj@kernel.org>:
[...]
> > > My current patch introduces a set of kernel ABIs (.../perf_events/<P>/*),
> > > and if I want to control another field in the perf_event_attr,
> > > I would have to add a new ABI. This would be a significant
> > > maintenance cost.
> > >
> > > Instead, I would like to provide a single bin file where the
> > > perf_event_attr I want to set is written as binary.
> >
> > I'd prefer having single file per parameter, as sysfs is designed for. It
> > allows keeping the input format simple and therefore easy to maintain and
> > extend. Of course, we should carefult at adding new parameters, though.
>
> Another idea from Namhyung Kim [1] is to fix the events
> specified by the CPU architecture being executed.
I think I need to study mroe about perf events :)
>
> Of course, we would want to control a limited number of
> parameters, such as sample_freq.
>
> [1] https://lore.kernel.org/damon/aZwLDAxf9eP0lPdD@z2/
>
> > >
> > > > >
> > > > > - `sample freq`: A higher frequency improves access accuracy, but also
> > > > > increases overhead.
> > > > > - `sample phys addr`: specify 0 for vaddr and 1 for paddr.
> > > > > - The remaining type, config, config1, and config2 settings can be found
> > > > > as follows:
> > > >
> > > > The values look bit human-unfriendly. I wonder if we could use more
> > > > human-friendly values, e.g., 'cpu' for type,
> > > > 'mem_trans_retired.load_latency_gt_1024' for config, etc. Not necessarily we
> > > > need to fix this right now. Let's keep discussing.
> > >
> > > I'd like to do it that way. These processes can be handled better
> > > from user space than from within the kernel, so I'd like to achieve
> > > this from damo with the help of the perf tool and library.
> >
> > Does existing perf event ABI also take that approach? If so, I think that is
> > fine.
>
> On Intel CPUs, you can read the mem-loads and/or mem-stores
> files as follows to find the value that should be set to
> perf_event_attr:
>
> $ cat /sys/bus/event_source/devices/cpu/events/mem-loads
> event=0xcd,umask=0x1,ldlat=3
>
> You can find out which bit field of which member of
> perf_event_attr should be used to set these values from the
> corresponding files in the format directory.
>
> $ cat /sys/bus/event_source/devices/cpu/format/{event,umask,ldlat}
> config:0-7
> config:8-15
> config1:0-15
>
> This conversion from symbolic event name to values that should
> be set in perf_event_attr can be done, for example, as shown below,
> so I think it should be implemented using perf in some way.
>
> import perf
>
> if __name__ == '__main__':
> evlist = perf.parse_events("mem-loads")
> for evsel in evlist:
> print(f"{evsel}: type={evsel.type} config={evsel.config}")
I definitely need to study mroe about perf event. I will comment after I learn
some fundamentals. But I believe this is not a blocker of this work.
Thanks,
SJ
next prev parent reply other threads:[~2026-04-25 15:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 0:42 [RFC PATCH v3 0/4] mm/damon: introduce perf event based access check Akinobu Mita
2026-04-23 0:42 ` [RFC PATCH v3 1/4] mm/damon/core: add code borrowed from report-based monitoring work Akinobu Mita
2026-04-23 1:21 ` sashiko-bot
2026-04-23 0:42 ` [RFC PATCH v3 2/4] mm/damon/core: add common code for perf event based access check Akinobu Mita
2026-04-23 1:58 ` sashiko-bot
2026-04-23 0:42 ` [RFC PATCH v3 3/4] mm/damon/vaddr: support " Akinobu Mita
2026-04-23 2:48 ` sashiko-bot
2026-04-23 0:42 ` [RFC PATCH v3 4/4] mm/damon/paddr: " Akinobu Mita
2026-04-23 3:22 ` sashiko-bot
2026-04-23 4:34 ` [RFC PATCH v3 0/4] mm/damon: introduce " SeongJae Park
2026-04-24 3:27 ` Akinobu Mita
2026-04-24 23:31 ` SeongJae Park
2026-04-25 12:33 ` Akinobu Mita
2026-04-25 15:33 ` SeongJae Park [this message]
2026-04-29 8:00 ` Namhyung Kim
2026-04-29 14:34 ` SeongJae Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260425153316.89358-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akinobu.mita@gmail.com \
--cc=damon@lists.linux.dev \
--cc=linux-perf-users@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.