tools/perf/util/header.c | 46 ++++++++++++++++++++++++++-------------- tools/perf/util/header.h | 1 + 2 files changed, 31 insertions(+), 16 deletions(-)
Pipe mode has no header and emits the data as if it were events. The dumping of features was controlled by the --header/-I options which makes little sense when they are events, normally traced when dump_trace is true. Switch to making pipe feature events also be traced with detail when other events are. The attr event in pipe mode had no dumping, wire this up and use the existing perf_event_attr fprintf support. The header's bpf_prog_info or bpf_btf may be empty when written. If they are empty just skip writing them to save space. Ian Rogers (4): perf header: In pipe mode dump features without --header/-I perf header: Allow tracing of attr events perf header: Display message if BPF/BTF info is empty perf header: Don't write empty BPF/BTF info tools/perf/util/header.c | 46 ++++++++++++++++++++++++++-------------- tools/perf/util/header.h | 1 + 2 files changed, 31 insertions(+), 16 deletions(-) -- 2.50.0.rc0.604.gd4ff7b7c86-goog
On Fri, 06 Jun 2025 23:12:34 -0700, Ian Rogers wrote: > Pipe mode has no header and emits the data as if it were events. The > dumping of features was controlled by the --header/-I options which > makes little sense when they are events, normally traced when > dump_trace is true. Switch to making pipe feature events also be > traced with detail when other events are. > > The attr event in pipe mode had no dumping, wire this up and use the > existing perf_event_attr fprintf support. > > [...] Applied to perf-tools-next, thanks! Best regards, Namhyung
On Fri, Jun 06, 2025 at 11:12:34PM -0700, Ian Rogers wrote:
> Pipe mode has no header and emits the data as if it were events. The
> dumping of features was controlled by the --header/-I options which
> makes little sense when they are events, normally traced when
> dump_trace is true. Switch to making pipe feature events also be
> traced with detail when other events are.
I'm not sure I'm following. Are you saying the pipe mode doesn't
support features with --header/-I option?
It seems to work for me.
$ git show
commit be59dba332e1e8edd3e88d991ba0e4795ae2bcb2 (HEAD -> perf-testing)
Author: Ian Rogers <irogers@google.com>
Date: Tue Jun 17 15:33:56 2025 -0700
libperf evsel: Add missed puts and asserts
A missed evsel__close before evsel__delete was the source of leaking
perf events due to a hybrid test. Add asserts in debug builds so that
this shouldn't happen in the future. Add puts missing on the cpu map
and thread maps.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250617223356.2752099-4-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
$ ./perf version
perf version 6.16.rc3.gbe59dba332e1
$ ./perf record -o- true | ./perf report -i- --header-only
# ========
# captured on : Tue Jun 24 12:06:38 2025
# header version : 1
# data offset : 0
# data size : 0
# feat offset : 0
# ========
#
# hostname : bangji
# os release : 6.12.20-1rodete1-amd64
# perf version : 6.16.rc3.gbe59dba332e1
# arch : x86_64
# nrcpus online : 4
# nrcpus avail : 8
# cpudesc : 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
# cpuid : GenuineIntel,6,140,1
# total memory : 32566540 kB
# cmdline : /home/namhyung/project/linux/tools/perf/perf record -o- true
# event : name = cycles:P, , id = { 369, 370, 371, 372 }, type = 0 (PERF_TYPE_HARDWARE), ...
# CPU_TOPOLOGY info available, use -I to display
# NUMA_TOPOLOGY info available, use -I to display
# pmu mappings: cpu = 4, breakpoint = 5, cstate_core = 22, cstate_pkg = 23, hwmon_acpitz = 4294901760, ...
# time of first sample : 0.000000
# time of last sample : 0.000000
# sample duration : 0.000 ms
# MEM_TOPOLOGY info available, use -I to display
# cpu pmu capabilities: branches=32, max_precise=3, pmu_name=icelake
# intel_pt pmu capabilities: topa_multiple_entries=1, psb_cyc=1, single_range_output=1, ...
>
> The attr event in pipe mode had no dumping, wire this up and use the
> existing perf_event_attr fprintf support.
>
> The header's bpf_prog_info or bpf_btf may be empty when written. If
> they are empty just skip writing them to save space.
These look good to me.
Thanks,
Namhyung
>
> Ian Rogers (4):
> perf header: In pipe mode dump features without --header/-I
> perf header: Allow tracing of attr events
> perf header: Display message if BPF/BTF info is empty
> perf header: Don't write empty BPF/BTF info
>
> tools/perf/util/header.c | 46 ++++++++++++++++++++++++++--------------
> tools/perf/util/header.h | 1 +
> 2 files changed, 31 insertions(+), 16 deletions(-)
>
> --
> 2.50.0.rc0.604.gd4ff7b7c86-goog
>
On Tue, Jun 24, 2025 at 12:11 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> On Fri, Jun 06, 2025 at 11:12:34PM -0700, Ian Rogers wrote:
> > Pipe mode has no header and emits the data as if it were events. The
> > dumping of features was controlled by the --header/-I options which
> > makes little sense when they are events, normally traced when
> > dump_trace is true. Switch to making pipe feature events also be
> > traced with detail when other events are.
>
> I'm not sure I'm following. Are you saying the pipe mode doesn't
> support features with --header/-I option?
No, in pipe mode it currently shows just PERF_RECORD_FEATURE or
PERF_RECORD_ATTR for the details of the events containing these
things. The reason being that the dumping is controlled by separate
header flags (--header and -I). In patch 1 the commit message shows
the before:
```
$ perf record -o - -a sleep 1 | perf script -D -i -
...
0x2c8@pipe [0x54]: event: 80
.
. ... raw event: size 84 bytes
. 0000: 50 00 00 00 00 00 54 00 05 00 00 00 00 00 00 00 P.....T.........
. 0010: 40 00 00 00 36 2e 31 35 2e 72 63 37 2e 67 61 64 @...6.15.rc7.gad
. 0020: 32 61 36 39 31 63 39 39 66 62 00 00 00 00 00 00 2a691c99fb......
. 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
. 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
. 0050: 00 00 00 00 ....
0 0 0x2c8 [0x54]: PERF_RECORD_FEATURE
```
That is we have a feature "event" but there are no details there to
try to be able to understand the feature event. After the change this
becomes:
```
$ perf record -o - -a sleep 1 | perf script -D -i -
...
0x2c8@pipe [0x54]: event: 80
.
. ... raw event: size 84 bytes
. 0000: 50 00 00 00 00 00 54 00 05 00 00 00 00 00 00 00 P.....T.........
. 0010: 40 00 00 00 36 2e 31 35 2e 72 63 37 2e 67 61 64 @...6.15.rc7.gad
. 0020: 32 61 36 39 31 63 39 39 66 62 00 00 00 00 00 00 2a691c99fb......
. 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
. 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
. 0050: 00 00 00 00 ....
0 0 0x2c8 [0x54]: PERF_RECORD_FEATURE, # perf version : 6.15.rc7.gad2a691c99fb
```
So now in the dump trace output I can see this was a feature for perf
version and what that value is. There are often multiple
PERF_RECORD_FEATURE and PERF_RECORD_ATTR "events" and so the extra
trace output helps in being able to work out what's going on.
Thanks,
Ian
> It seems to work for me.
>
> $ git show
> commit be59dba332e1e8edd3e88d991ba0e4795ae2bcb2 (HEAD -> perf-testing)
> Author: Ian Rogers <irogers@google.com>
> Date: Tue Jun 17 15:33:56 2025 -0700
>
> libperf evsel: Add missed puts and asserts
>
> A missed evsel__close before evsel__delete was the source of leaking
> perf events due to a hybrid test. Add asserts in debug builds so that
> this shouldn't happen in the future. Add puts missing on the cpu map
> and thread maps.
>
> Signed-off-by: Ian Rogers <irogers@google.com>
> Link: https://lore.kernel.org/r/20250617223356.2752099-4-irogers@google.com
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
>
> $ ./perf version
> perf version 6.16.rc3.gbe59dba332e1
>
> $ ./perf record -o- true | ./perf report -i- --header-only
> # ========
> # captured on : Tue Jun 24 12:06:38 2025
> # header version : 1
> # data offset : 0
> # data size : 0
> # feat offset : 0
> # ========
> #
> # hostname : bangji
> # os release : 6.12.20-1rodete1-amd64
> # perf version : 6.16.rc3.gbe59dba332e1
> # arch : x86_64
> # nrcpus online : 4
> # nrcpus avail : 8
> # cpudesc : 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
> # cpuid : GenuineIntel,6,140,1
> # total memory : 32566540 kB
> # cmdline : /home/namhyung/project/linux/tools/perf/perf record -o- true
> # event : name = cycles:P, , id = { 369, 370, 371, 372 }, type = 0 (PERF_TYPE_HARDWARE), ...
> # CPU_TOPOLOGY info available, use -I to display
> # NUMA_TOPOLOGY info available, use -I to display
> # pmu mappings: cpu = 4, breakpoint = 5, cstate_core = 22, cstate_pkg = 23, hwmon_acpitz = 4294901760, ...
> # time of first sample : 0.000000
> # time of last sample : 0.000000
> # sample duration : 0.000 ms
> # MEM_TOPOLOGY info available, use -I to display
> # cpu pmu capabilities: branches=32, max_precise=3, pmu_name=icelake
> # intel_pt pmu capabilities: topa_multiple_entries=1, psb_cyc=1, single_range_output=1, ...
>
> >
> > The attr event in pipe mode had no dumping, wire this up and use the
> > existing perf_event_attr fprintf support.
> >
> > The header's bpf_prog_info or bpf_btf may be empty when written. If
> > they are empty just skip writing them to save space.
>
> These look good to me.
>
> Thanks,
> Namhyung
>
> >
> > Ian Rogers (4):
> > perf header: In pipe mode dump features without --header/-I
> > perf header: Allow tracing of attr events
> > perf header: Display message if BPF/BTF info is empty
> > perf header: Don't write empty BPF/BTF info
> >
> > tools/perf/util/header.c | 46 ++++++++++++++++++++++++++--------------
> > tools/perf/util/header.h | 1 +
> > 2 files changed, 31 insertions(+), 16 deletions(-)
> >
> > --
> > 2.50.0.rc0.604.gd4ff7b7c86-goog
> >
On Tue, Jun 24, 2025 at 01:15:13PM -0700, Ian Rogers wrote: > On Tue, Jun 24, 2025 at 12:11 PM Namhyung Kim <namhyung@kernel.org> wrote: > > > > On Fri, Jun 06, 2025 at 11:12:34PM -0700, Ian Rogers wrote: > > > Pipe mode has no header and emits the data as if it were events. The > > > dumping of features was controlled by the --header/-I options which > > > makes little sense when they are events, normally traced when > > > dump_trace is true. Switch to making pipe feature events also be > > > traced with detail when other events are. > > > > I'm not sure I'm following. Are you saying the pipe mode doesn't > > support features with --header/-I option? > > No, in pipe mode it currently shows just PERF_RECORD_FEATURE or > PERF_RECORD_ATTR for the details of the events containing these > things. The reason being that the dumping is controlled by separate > header flags (--header and -I). In patch 1 the commit message shows > the before: > ``` > $ perf record -o - -a sleep 1 | perf script -D -i - > ... > 0x2c8@pipe [0x54]: event: 80 > . > . ... raw event: size 84 bytes > . 0000: 50 00 00 00 00 00 54 00 05 00 00 00 00 00 00 00 P.....T......... > . 0010: 40 00 00 00 36 2e 31 35 2e 72 63 37 2e 67 61 64 @...6.15.rc7.gad > . 0020: 32 61 36 39 31 63 39 39 66 62 00 00 00 00 00 00 2a691c99fb...... > . 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0050: 00 00 00 00 .... > > 0 0 0x2c8 [0x54]: PERF_RECORD_FEATURE > ``` > > That is we have a feature "event" but there are no details there to > try to be able to understand the feature event. After the change this > becomes: > ``` > $ perf record -o - -a sleep 1 | perf script -D -i - > ... > 0x2c8@pipe [0x54]: event: 80 > . > . ... raw event: size 84 bytes > . 0000: 50 00 00 00 00 00 54 00 05 00 00 00 00 00 00 00 P.....T......... > . 0010: 40 00 00 00 36 2e 31 35 2e 72 63 37 2e 67 61 64 @...6.15.rc7.gad > . 0020: 32 61 36 39 31 63 39 39 66 62 00 00 00 00 00 00 2a691c99fb...... > . 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0050: 00 00 00 00 .... > > 0 0 0x2c8 [0x54]: PERF_RECORD_FEATURE, # perf version : 6.15.rc7.gad2a691c99fb > ``` > > So now in the dump trace output I can see this was a feature for perf > version and what that value is. There are often multiple > PERF_RECORD_FEATURE and PERF_RECORD_ATTR "events" and so the extra > trace output helps in being able to work out what's going on. Thanks for the clarification, I was confused if it's fixing -I or -D. :) Namhyung
© 2016 - 2025 Red Hat, Inc.