Re: [External] Re: [RFC 00/12] perf record: Add event action support

[Ian Rogers]

On Wed, Dec 4, 2024 at 12:35 AM Yang Jihong <yangjihong@xxxxxxxxxxxxx> wrote:
>
> Hello,
>
> On 12/3/24 05:46, Namhyung Kim wrote:
> > Hello,
> >
> > On Thu, Nov 28, 2024 at 05:14:53PM -0300, Arnaldo Carvalho de Melo wrote:
> >> On Thu, Nov 28, 2024 at 09:35:41PM +0800, Yang Jihong wrote:
> >>> In perf-record, when an event is triggered, default behavior is to
> >>> save sample data to perf.data. Sometimes, we may just want to do
> >>> some lightweight actions, such as printing a log.
> >>
> >>> Based on this requirement, add the --action option to the event to
> >>> specify the behavior when the event occurs.
> >>
> >> 'perf record' is centered on saving data to disk without processing
> >> events, while it has sideband events for some needs, like processing BPF
> >> related events (PERF_RECORD_BPF_EVENT to catch PERF_BPF_EVENT_PROG_LOAD
> >> and UNLOAD), doing things in a "live" way as your patchkit does seems
> >> more appropriate to do in 'perf trace' :-)
> >
> > Agreed, 'perf trace' looks like a better place as you seem to target
> > tracepoint events mostly.
> >
> Okay, will do it in 'perf trace'.
>
> Attaching to a kprobe events will also be supported in the future.

Hi Yang,

Just some extra information in case it is useful on python scripting,
which could be reused to avoid writing a new interpreter as in this
series. There are quite a few perf script examples here:
https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/scripts/python?h=perf-tools-next
There are also standalone scripts here including for tracepoints:
https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/python?h=perf-tools-next
One of the things missing for standalone scripts was being able to
conveniently parse events - you'd need to manually determine PMU type
and config values. That is fixed in this reviewed but not merged
series:
https://lore.kernel.org/lkml/20241119011644.971342-1-irogers@xxxxxxxxxx/

I'd like to see the python code improved as it allows quicker command
creation like your example. Another example I'd recently tweaked is:
https://lore.kernel.org/lkml/20241119180130.19160-1-irogers@xxxxxxxxxx/
Ultimately I think it would be nice to be creating tools using UIs
like textualize:
https://www.textualize.io/
and our Gecko Google summer-of-code project was an improvement here:
https://lore.kernel.org/lkml/ZOrsiZA+C0zbWEQS@yoga/

Other than basic functionality, perf's python support could be
improved in a number of ways that we've discussed in office hours or
on the list. Some things that come to mind:
1) The perf script callback mechanism doesn't feel particularly
pythonic, generators or coroutines could be better.
2) We should probably have more library python code rather than adding
new functions to `tools/perf/util/python.c` - I may do this to add
type hints for mypy. If we could have a subset that works without the
C code then it could be a basis for `perf.data` file analysis not tied
to Linux, or `pip install`-able. There is a similar library with
simpleperf, but shipping something with the perf codebase means we can
keep the file format and library synchronized.
3) We'd like to reduce the number of dependencies `perf` as a command
has, and libpython is a big one. Something `uftrace` did was dlopen
libpython to avoid needing to link against it. A project similarly
rethinking python binding with C code is HPy.

Thanks,
Ian