From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>, Ian Rogers <irogers@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Namhyung Kim <namhyung@kernel.org>, Song Liu <song@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Clark Williams <williams@redhat.com>,
Kate Carcia <kcarcia@redhat.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Adrian Hunter <adrian.hunter@intel.com>,
Changbin Du <changbin.du@huawei.com>, Hao Luo <haoluo@google.com>,
James Clark <james.clark@arm.com>,
Kan Liang <kan.liang@linux.intel.com>,
Roman Lozko <lozko.roma@gmail.com>,
Stephane Eranian <eranian@google.com>,
Thomas Richter <tmricht@linux.ibm.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Yang Jihong <yangjihong1@huawei.com>,
Mark Rutland <mark.rutland@arm.com>, Paul Clarke <pc@us.ibm.com>
Subject: Re: [PATCH RFC/RFT] perf bpf skels: Stop using vmlinux.h generated from BTF, use subset of used structs + CO-RE. was Re: BPF skels in perf .Re: [GIT PULL] perf tools changes for v6.4
Date: Fri, 5 May 2023 18:52:04 -0300 [thread overview]
Message-ID: <ZFV6hFG/YMiF8vY0@kernel.org> (raw)
In-Reply-To: <CAEf4BzYYnpD6+GSg+wfL1wUY5YasbN2-9NPJ3QkGZ9o963uYdA@mail.gmail.com>
Em Fri, May 05, 2023 at 02:21:56PM -0700, Andrii Nakryiko escreveu:
> On Fri, May 5, 2023 at 2:15 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > On Fri, May 05, 2023 at 01:46:30PM -0700, Ian Rogers wrote:
> > > On Fri, May 5, 2023 at 1:43 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> > > >
> > > > On Fri, May 05, 2023 at 10:04:47AM -0700, Ian Rogers wrote:
> > > > > On Fri, May 5, 2023 at 9:56 AM Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > > > > >
> > > > > > Em Fri, May 05, 2023 at 10:33:15AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > > > > Em Fri, May 05, 2023 at 01:03:14AM +0200, Jiri Olsa escreveu:
> > > > > > > That with the preserve_access_index isn't needed, we need just the
> > > > > > > fields that we access in the tools, right?
> > > > > >
> > > > > > I'm now doing build test this in many distro containers, without the two
> > > > > > reverts, i.e. BPF skels continue as opt-out as in my pull request, to
> > > > > > test build and also for the functionality tests on the tools using such
> > > > > > bpf skels, see below, no touching of vmlinux nor BTF data during the
> > > > > > build.
> > > > > >
> > > > > > - Arnaldo
> > > > > >
> > > > > > From 882adaee50bc27f85374aeb2fbaa5b76bef60d05 Mon Sep 17 00:00:00 2001
> > > > > > From: Arnaldo Carvalho de Melo <acme@redhat.com>
> > > > > > Date: Thu, 4 May 2023 19:03:51 -0300
> > > > > > Subject: [PATCH 1/1] perf bpf skels: Stop using vmlinux.h generated from BTF,
> > > > > > use subset of used structs + CO-RE
> > > > > >
> > > > > > Linus reported a build break due to using a vmlinux without a BTF elf
> > > > > > section to generate the vmlinux.h header with bpftool for use in the BPF
> > > > > > tools in tools/perf/util/bpf_skel/*.bpf.c.
> > > > > >
> > > > > > Instead add a vmlinux.h file with the structs needed with the fields the
> > > > > > tools need, marking the structs with __attribute__((preserve_access_index)),
> > > > > > so that libbpf's CO-RE code can fixup the struct field offsets.
> > > > > >
> > > > > > In some cases the vmlinux.h file that was being generated by bpftool
> > > > > > from the kernel BTF information was not needed at all, just including
> > > > > > linux/bpf.h, sometimes linux/perf_event.h was enough as non-UAPI
> > > > > > types were not being used.
> > > > > >
> > > > > > To keep te patch small, include those UAPI headers from the trimmed down
> > > > > > vmlinux.h file, that then provides the tools with just the structs and
> > > > > > the subset of its fields needed for them.
> > > > > >
> > > > > > Testing it:
> > > > > >
> > > > > > # perf lock contention -b find / > /dev/null
> > > >
> > > > I tested perf lock con -abv -L rcu_state sleep 1
> > > > and needed fix below
> > > >
> > > > jirka
> > >
> > > I thought this was fixed by:
> > > https://lore.kernel.org/lkml/20230427234833.1576130-1-namhyung@kernel.org/
> > > but I think that is just in perf-tools-next.
> >
> > ah ok, missed that one
>
> Please try validating with veristat to check if all of perf's .bpf.o
> files are successful. Veristat is part of selftests and can be built
> with just `make -C tools/testing/selftests/bpf veristat`. After that;
>
> sudo ~/bin/veristat tools/perf/util/bpf_skel/.tmp/*.bpf.o
>
> This is a surer way to check that BPF object files are ok at least on
> your currently running kernel, than trying to exercise each BPF
> program through perf commands.
[acme@quaco perf-tools]$ sudo tools/testing/selftests/bpf/veristat /tmp/build/perf-tools/util/bpf_skel/.tmp/*.bpf.o
Processing 'bperf_cgroup.bpf.o'...
Processing 'bperf_follower.bpf.o'...
Processing 'bperf_leader.bpf.o'...
Processing 'bpf_prog_profiler.bpf.o'...
Processing 'func_latency.bpf.o'...
Processing 'kwork_trace.bpf.o'...
Processing 'lock_contention.bpf.o'...
Processing 'off_cpu.bpf.o'...
Processing 'sample_filter.bpf.o'...
File Program Verdict Duration (us) Insns States Peak states
----------------------- ------------------------------- ------- ------------- ------ ------ -----------
bperf_cgroup.bpf.o on_cgrp_switch success 6479 17025 417 174
bperf_cgroup.bpf.o trigger_read success 6370 17025 417 174
bperf_follower.bpf.o fexit_XXX failure 0 0 0 0
bperf_leader.bpf.o on_switch success 360 49 3 3
bpf_prog_profiler.bpf.o fentry_XXX failure 0 0 0 0
bpf_prog_profiler.bpf.o fexit_XXX failure 0 0 0 0
func_latency.bpf.o func_begin success 351 69 6 6
func_latency.bpf.o func_end success 318 158 15 15
kwork_trace.bpf.o latency_softirq_entry success 334 108 10 10
kwork_trace.bpf.o latency_softirq_raise success 896 1993 34 34
kwork_trace.bpf.o latency_workqueue_activate_work success 333 46 4 4
kwork_trace.bpf.o latency_workqueue_execute_start success 1112 2219 41 41
kwork_trace.bpf.o report_irq_handler_entry success 1067 2118 34 34
kwork_trace.bpf.o report_irq_handler_exit success 334 110 10 10
kwork_trace.bpf.o report_softirq_entry success 897 1993 34 34
kwork_trace.bpf.o report_softirq_exit success 329 108 10 10
kwork_trace.bpf.o report_workqueue_execute_end success 1124 2219 41 41
kwork_trace.bpf.o report_workqueue_execute_start success 295 46 4 4
lock_contention.bpf.o collect_lock_syms failure 0 0 0 0
lock_contention.bpf.o contention_begin failure 0 0 0 0
lock_contention.bpf.o contention_end failure 0 0 0 0
off_cpu.bpf.o on_newtask success 387 37 3 3
off_cpu.bpf.o on_switch success 536 220 20 20
sample_filter.bpf.o perf_sample_filter success 190443 190237 11173 923
----------------------- ------------------------------- ------- ------------- ------ ------ -----------
Done. Processed 9 files, 0 programs. Skipped 24 files, 0 programs.
[acme@quaco perf-tools]$
What extra info can we get from these "failure" lines?
- Arnaldo
next prev parent reply other threads:[~2023-05-05 21:52 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-03 21:18 [GIT PULL] perf tools changes for v6.4 Arnaldo Carvalho de Melo
2023-05-04 3:00 ` Linus Torvalds
2023-05-04 3:12 ` Linus Torvalds
2023-05-04 5:51 ` Ian Rogers
2023-05-04 18:36 ` Jiri Olsa
2023-05-04 11:09 ` BPF skels in perf .Re: " Arnaldo Carvalho de Melo
2023-05-04 17:25 ` Linus Torvalds
2023-05-04 17:52 ` Arnaldo Carvalho de Melo
2023-05-04 18:50 ` Andrii Nakryiko
2023-05-04 19:07 ` Arnaldo Carvalho de Melo
2023-05-04 21:48 ` Arnaldo Carvalho de Melo
2023-05-04 22:01 ` Arnaldo Carvalho de Melo
2023-05-05 13:18 ` Arnaldo Carvalho de Melo
2023-05-06 1:13 ` Yang Jihong
2023-05-05 13:20 ` Arnaldo Carvalho de Melo
2023-05-04 22:03 ` Ian Rogers
2023-05-04 23:03 ` Jiri Olsa
2023-05-04 23:15 ` Namhyung Kim
2023-05-05 9:36 ` Jiri Olsa
2023-05-04 23:19 ` Ian Rogers
2023-05-05 9:39 ` Jiri Olsa
2023-05-05 11:42 ` Jiri Olsa
2023-05-05 13:33 ` Arnaldo Carvalho de Melo
2023-05-05 15:14 ` Alexei Starovoitov
2023-05-05 16:56 ` [PATCH RFC/RFT] perf bpf skels: Stop using vmlinux.h generated from BTF, use subset of used structs + CO-RE. was " Arnaldo Carvalho de Melo
2023-05-05 17:04 ` Ian Rogers
2023-05-05 20:43 ` Jiri Olsa
2023-05-05 20:46 ` Ian Rogers
2023-05-05 20:48 ` Namhyung Kim
2023-05-10 18:56 ` Arnaldo Carvalho de Melo
2023-05-05 20:49 ` Arnaldo Carvalho de Melo
2023-05-05 21:15 ` Jiri Olsa
2023-05-05 21:21 ` Andrii Nakryiko
2023-05-05 21:52 ` Arnaldo Carvalho de Melo [this message]
2023-05-05 21:55 ` Andrii Nakryiko
2023-05-05 21:33 ` Arnaldo Carvalho de Melo
2023-05-08 21:53 ` Ian Rogers
2023-05-04 22:46 ` Namhyung Kim
2023-05-07 19:15 ` pr-tracker-bot
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=ZFV6hFG/YMiF8vY0@kernel.org \
--to=acme@kernel.org \
--cc=acme@redhat.com \
--cc=adrian.hunter@intel.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=changbin.du@huawei.com \
--cc=eranian@google.com \
--cc=haoluo@google.com \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=kan.liang@linux.intel.com \
--cc=kcarcia@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=lozko.roma@gmail.com \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=olsajiri@gmail.com \
--cc=pc@us.ibm.com \
--cc=song@kernel.org \
--cc=tglx@linutronix.de \
--cc=tmricht@linux.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=williams@redhat.com \
--cc=yangjihong1@huawei.com \
/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.