| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 18 Nov 2022 16:37:12 -0800
From: Namhyung Kim <namhyung@...nel.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Peter Zijlstra <peterz@...radead.org>,
Ian Rogers <irogers@...gle.com>,
Ingo Molnar <mingo@...hat.com>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
Steven Rostedt <rostedt@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Linux Trace Devel <linux-trace-devel@...r.kernel.org>,
Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH v1 1/2] perf build: Require libtraceevent from the system
Hi,
On Fri, Nov 18, 2022 at 8:34 AM Arnaldo Carvalho de Melo
<acme@...nel.org> wrote:
>
> Em Fri, Nov 18, 2022 at 10:33:02AM -0500, Steven Rostedt escreveu:
> > On Fri, 18 Nov 2022 12:02:38 -0300 Arnaldo Carvalho de Melo <acme@...nel.org> wrote:
>
> > > yeah, this probably should work like with other libraries, don't stop
> > > the build, just don't build features that depend on libtraceevent,
> > > warning the user that features foo, bar and baz won't be available.
>
> > > For people working with just hardware, software, cache events, no
> > > problem.
>
> > How are software events parsed?
>
> Not parsed, fixed:
I believe Steve meant tracepoints :)
>
> root@...-rk3399-pc:~# perf list sw
>
> List of pre-defined events (to be used in -e or -M):
>
> alignment-faults [Software event]
> bpf-output [Software event]
> cgroup-switches [Software event]
> context-switches OR cs [Software event]
> cpu-clock [Software event]
> cpu-migrations OR migrations [Software event]
> dummy [Software event]
> emulation-faults [Software event]
> major-faults [Software event]
> minor-faults [Software event]
> page-faults OR faults [Software event]
> task-clock [Software event]
>
> duration_time [Tool event]
> user_time [Tool event]
> system_time [Tool event]
>
> root@...-rk3399-pc:~#
>
>
> In addition to:
>
> root@...-rk3399-pc:~# perf list hw
>
> List of pre-defined events (to be used in -e or -M):
>
> branch-instructions OR branches [Hardware event]
> branch-misses [Hardware event]
> bus-cycles [Hardware event]
> cache-misses [Hardware event]
> cache-references [Hardware event]
> cpu-cycles OR cycles [Hardware event]
> instructions [Hardware event]
>
> root@...-rk3399-pc:~#
>
> And:
>
> root@...-rk3399-pc:~# perf list cache
>
> List of pre-defined events (to be used in -e or -M):
>
> L1-dcache-load-misses [Hardware cache event]
> L1-dcache-loads [Hardware cache event]
> L1-dcache-prefetch-misses [Hardware cache event]
> L1-dcache-store-misses [Hardware cache event]
> L1-dcache-stores [Hardware cache event]
> L1-icache-load-misses [Hardware cache event]
> L1-icache-loads [Hardware cache event]
> branch-load-misses [Hardware cache event]
> branch-loads [Hardware cache event]
> dTLB-load-misses [Hardware cache event]
> dTLB-store-misses [Hardware cache event]
> iTLB-load-misses [Hardware cache event]
> node-loads [Hardware cache event]
> node-stores [Hardware cache event]
>
> root@...-rk3399-pc:~#
>
> Without something like libtraceevent 'perf probe', 'perf trace' wouldn't
> work as of now, as it currently use libtraceevent to parse whats in
> tracefs.
Right, many other tools would be impacted like 'perf lock', 'perf sched', ...
>
> So for some people, just interested in profiling the above hw, sw and
> cache events, libtraceevent isn't strictly required and may even be
> desirable to reduce the number of library dependencies.
>
> So its a valid feature to allow perf to be built without libtraceevent,
> i.e. not something needed for the above scenarios.
Right, we could remove unsupported commands from the build or
refuse to run them with a warning.
Thanks,
Namhyung
>
> With libbpf and BTF tracefs isn't also strictly needed, as we already
> have to link with it and things like 'perf trace' want to use libbpf's
> btf pretty printing stuff, we can use BTF to enumerate events, iterate
> thru its fields, offsets, types, etc:
>
> root@...-rk3399-pc:~# pahole --sizes | grep trace_event_raw_sched
> trace_event_raw_sched_kthread_stop 28 0
> trace_event_raw_sched_kthread_stop_ret 12 0
> trace_event_raw_sched_kthread_work_queue_work 32 0
> trace_event_raw_sched_kthread_work_execute_start 24 0
> trace_event_raw_sched_kthread_work_execute_end 24 0
> trace_event_raw_sched_wakeup_template 36 0
> trace_event_raw_sched_switch 64 0
> trace_event_raw_sched_migrate_task 40 0
> trace_event_raw_sched_process_template 32 0
> trace_event_raw_sched_process_wait 32 0
> trace_event_raw_sched_process_fork 48 0
> trace_event_raw_sched_process_exec 20 0
> trace_event_raw_sched_stat_runtime 48 1
> trace_event_raw_sched_pi_setprio 36 0
> trace_event_raw_sched_move_numa 36 0
> trace_event_raw_sched_numa_pair_template 48 0
> trace_event_raw_sched_wake_idle_without_ipi 12 0
> root@...-rk3399-pc:~#
>
> root@...-rk3399-pc:~# pahole trace_event_raw_sched_switch
> struct trace_event_raw_sched_switch {
> struct trace_entry ent; /* 0 8 */
> char prev_comm[16]; /* 8 16 */
> pid_t prev_pid; /* 24 4 */
> int prev_prio; /* 28 4 */
> long int prev_state; /* 32 8 */
> char next_comm[16]; /* 40 16 */
> pid_t next_pid; /* 56 4 */
> int next_prio; /* 60 4 */
> /* --- cacheline 1 boundary (64 bytes) --- */
> char __data[]; /* 64 0 */
>
> /* size: 64, cachelines: 1, members: 9 */
> };
> root@...-rk3399-pc:~#
>
> - Arnaldo
Powered by blists - more mailing lists