Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221117224952.358639-1-irogers@google.com> <20221117224952.358639-2-irogers@google.com>
 <Y3dQxVNwGmQMWPP0@hirez.programming.kicks-ass.net> <Y3eejjLjChlGC96I@kernel.org>
 <20221118103302.7ea12016@gandalf.local.home> <Y3ez+y/k1dIip5hH@kernel.org>
In-Reply-To: <Y3ez+y/k1dIip5hH@kernel.org>
From:   Namhyung Kim <namhyung@kernel.org>
Date:   Fri, 18 Nov 2022 16:37:12 -0800
Message-ID: <CAM9d7chHHuULqNS-YWj=LU=Q0E10zjMe5=HTnBREa4=YmQGPpA@mail.gmail.com>
Subject: Re: [PATCH v1 1/2] perf build: Require libtraceevent from the system
To:     Arnaldo Carvalho de Melo <acme@kernel.org>
Cc:     Steven Rostedt <rostedt@goodmis.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Ian Rogers <irogers@google.com>,
        Ingo Molnar <mingo@redhat.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Jiri Olsa <jolsa@kernel.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
        Steven Rostedt <rostedt@google.com>,
        Adrian Hunter <adrian.hunter@intel.com>,
        Linux Trace Devel <linux-trace-devel@vger.kernel.org>,
        Stephane Eranian <eranian@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

On Fri, Nov 18, 2022 at 8:34 AM Arnaldo Carvalho de Melo
<acme@kernel.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@kernel.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@roc-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@roc-rk3399-pc:~#
>
>
> In addition to:
>
> root@roc-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@roc-rk3399-pc:~#
>
> And:
>
> root@roc-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@roc-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@roc-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@roc-rk3399-pc:~#
>
> root@roc-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@roc-rk3399-pc:~#
>
> - Arnaldo