All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Ian Rogers <irogers@google.com>,
	Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	namhyung@kernel.org
Subject: Re: linux-next: build failure after merge of the perf tree
Date: Thu, 23 Mar 2023 10:27:36 -0300	[thread overview]
Message-ID: <ZBxTyLqkIaoVhIXU@kernel.org> (raw)
In-Reply-To: <20230323095437.1ecccec1@canb.auug.org.au>

Em Thu, Mar 23, 2023 at 09:54:37AM +1100, Stephen Rothwell escreveu:
> Hi Ian,
> 
> On Wed, 22 Mar 2023 11:37:31 -0700 Ian Rogers <irogers@google.com> wrote:
> >
> > On Tue, Mar 21, 2023 at 2:40 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Hi all,
> > >
> > > On Fri, 17 Mar 2023 09:50:25 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> > > >
> > > > After merging the perf tree, today's linux-next build (native perf)
> > > > failed like this:
> > > >
> > > > Auto-detecting system features:
> > > > ...                         clang-bpf-co-re: [  [32mon [m  ]
> > > > ...                                    llvm: [  [31mOFF [m ]
> > > > ...                                  libcap: [  [32mon [m  ]
> > > > ...                                  libbfd: [  [32mon [m  ]
> > > >
> > > > make[1]: *** Deleting file '/home/sfr/next/perf/util/bpf_skel/vmlinux.h'
> > > > libbpf: failed to find '.BTF' ELF section in /boot/vmlinux-6.0.0-5-powerpc64le
> > > > Error: failed to load BTF from /boot/vmlinux-6.0.0-5-powerpc64le: No data available
> > > > make[1]: *** [Makefile.perf:1075: /home/sfr/next/perf/util/bpf_skel/vmlinux.h] Error 195
> > > > make[1]: *** Waiting for unfinished jobs....
> > > > make: *** [Makefile.perf:236: sub-make] Error 2
> > > > Command exited with non-zero status 2
> > > >
> > > > To be clear this is a native build of perf on a PPC64le host using this
> > > > command line:
> > > >
> > > > make -C tools/perf -f Makefile.perf -s -O -j60 O=../perf EXTRA_CFLAGS=-Wno-psabi
> > > >
> > > > (I could probably remove the EXTRA_CLFAGS now that I am building with
> > > > gcc 12.2)
> > > >
> > > > I don't know which commit caused this.
> > > >
> > > > I have used the perf tree from next-20230316 for today.  
> > >
> > > I am still getting this build failure.  

> > The build failure is intentional as not having BPF skeleton support in
> > the perf tool will remove features. I've just sent:
> > https://lore.kernel.org/lkml/20230322183108.1380882-1-irogers@google.com/
> > Which will recommend adding NO_BPF_SKEL=1 to your build options when
> > this failure occurs. I didn't think a features test was appropriate
> > for this as the feature test would basically replicate the vmlinux.h
> > generation and I didn't want to move that support through the build
> > system.
 
> I was trying to understand why this step fails, but from the error
> messages, it seems to require something to be present in the distro
> supplied kernel image?  Is there something missing from the ppc
> build process?  Or toolchain?  Why is it looking at the installed
> kernel and not the built kernel?  Does the perf build now depend on the
> kernel being built first?
> 
> I will add NO_BPF_SKEL=1 to my build from tomorrow, but surely that
> means that we miss some perf build testing :-(

Before this BUILD_BPF_SKEL wasn't on by default, so you're back testing
as much as before.

Having said that, we need to improve the warning and I processed a patch
from Ian to that extent:

https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=tmp.perf-tools-next&id=12a83df53444165d39d3e09fcd9627e7bec7828e

 $(SKEL_OUT)/vmlinux.h: $(VMLINUX_BTF) $(BPFTOOL)
 ifeq ($(VMLINUX_H),)
-	$(QUIET_GEN)$(BPFTOOL) btf dump file $< format c > $@
+	$(QUIET_GEN)$(BPFTOOL) btf dump file $< format c > $@ || \
+	(echo "Failure to generate vmlinux.h needed for the recommended BPF skeleton support." && \
+	echo "To disable this use the build option NO_BPF_SKEL=1." && \
+	echo "Alternatively point at a pre-generated vmlinux.h with VMLINUX_H=<path>." && \
+	false)
 else
 	$(Q)cp "$(VMLINUX_H)" $@
 endif

 Which improves a bit the situation.

We could check if bpftool is available and if not, suggest installing
it.

If it is available, we could check if /sys/kernel/bpf/ is available, if
not suggest using a kernel with CONFIG_DEBUG_INFO_BTF=y, as most distros
have by now.

As to the features this enables:

⬢[acme@toolbox perf-tools-next]$ ls -la tools/perf/util/bpf_skel/*.c
-rw-r--r--. 1 acme acme 5581 Oct 17 09:07 tools/perf/util/bpf_skel/bperf_cgroup.bpf.c
-rw-r--r--. 1 acme acme 1764 May  5  2022 tools/perf/util/bpf_skel/bperf_follower.bpf.c
-rw-r--r--. 1 acme acme 1438 May  5  2022 tools/perf/util/bpf_skel/bperf_leader.bpf.c
-rw-r--r--. 1 acme acme 2290 May  5  2022 tools/perf/util/bpf_skel/bpf_prog_profiler.bpf.c
-rw-r--r--. 1 acme acme 2164 May  5  2022 tools/perf/util/bpf_skel/func_latency.bpf.c
-rw-r--r--. 1 acme acme 9017 Aug 26  2022 tools/perf/util/bpf_skel/kwork_trace.bpf.c
-rw-r--r--. 1 acme acme 9251 Mar 14 08:33 tools/perf/util/bpf_skel/lock_contention.bpf.c
-rw-r--r--. 1 acme acme 6109 Feb 27 17:47 tools/perf/util/bpf_skel/off_cpu.bpf.c
-rw-r--r--. 1 acme acme 4310 Mar 15 11:08 tools/perf/util/bpf_skel/sample_filter.bpf.c
⬢[acme@toolbox perf-tools-next]$

For instance, take a look at these csets:

⬢[acme@toolbox perf-tools-next]$ git log --oneline tools/perf/util/bpf_skel/lock_contention.bpf.c
d24c0144b1dde00f perf lock contention: Show per-cpu rq_lock with address
1811e82767dcc6eb perf lock contention: Track and show siglock with address
3ace2435bb93445e perf lock contention: Track and show mmap_lock with address
17535a33a9c1e4fb perf lock contention: Fix compiler builtin detection
1bece1351c653c3d perf lock contention: Support old rw_semaphore type
3477f079fe70b3c9 perf lock contention: Add -o/--lock-owner option
ebab291641bed48f perf lock contention: Support filters for different aggregation
5e3febe7b7b99f94 perf lock contention: Support lock addr/name filtering for BPF
529772c4df286159 perf lock contention: Support lock type filtering for BPF
688d2e8de231c54e perf lock contention: Add -l/--lock-addr option
eca949b2b4addd94 perf lock contention: Implement -t/--threads option for BPF
fd507d3e359c7e06 perf lock contention: Add lock_data.h for common data
c66a36af7ba3a628 perf lock contention: Do not use BPF task local storage
433b31fa00797a2a perf lock contention: Fix a build error on 32-bit
c1da8dd5c11dabd5 perf lock contention: Skip stack trace from BPF
6d499a6b3d90277d perf lock: Print the number of lost entries for BPF
6fda2405f414b24a perf lock: Implement cpu and task filters for BPF
407b36f69efbdccf perf lock: Use BPF for lock contention analysis
⬢[acme@toolbox perf-tools-next]$


or:

⬢[acme@toolbox perf-tools-next]$ git log --oneline tools/perf/util/bpf_skel/kwork_trace.bpf.c
acfb65fe1d11a97f perf kwork: Add workqueue trace BPF support
5a81927a407c050a perf kwork: Add softirq trace BPF support
420298aefe94840f perf kwork: Add IRQ trace BPF support
daf07d220710a3c8 perf kwork: Implement BPF trace
⬢[acme@toolbox perf-tools-next]$

So we need to fine tune this detection of needed components to build
these features, in time for the v6.4 merge window, that is why we
decided  to make this opt-out to hammer out problems.

Other arches probably will hit some of these problems, lets try to
encourage others to try what is in linux-next.

- Arnaldo

  reply	other threads:[~2023-03-23 13:27 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-16 22:50 linux-next: build failure after merge of the perf tree Stephen Rothwell
2023-03-16 23:11 ` Arnaldo Carvalho de Melo
2023-03-16 23:55   ` Stephen Rothwell
2023-03-17  3:23     ` Ian Rogers
2023-03-21 21:39 ` Stephen Rothwell
2023-03-22 18:37   ` Ian Rogers
2023-03-22 22:54     ` Stephen Rothwell
2023-03-23 13:27       ` Arnaldo Carvalho de Melo [this message]
2023-03-27 20:31         ` Ian Rogers
2023-03-28  1:33         ` Stephen Rothwell
2023-03-28 19:47           ` Arnaldo Carvalho de Melo
2023-03-28 23:06             ` Stephen Rothwell
2023-03-29 12:28               ` Arnaldo Carvalho de Melo
2023-04-03  5:15                 ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2024-04-01 22:41 Stephen Rothwell
2024-04-02 20:17 ` Arnaldo Carvalho de Melo
2024-04-12 15:22 ` Arnaldo Carvalho de Melo
2024-04-13  2:43   ` Stephen Rothwell
2024-03-21 21:41 Stephen Rothwell
2024-03-21 23:18 ` Arnaldo Carvalho de Melo
2024-03-21 23:19   ` Arnaldo Carvalho de Melo
2024-03-21 23:32     ` Stephen Rothwell
2024-03-22  2:13       ` Stephen Rothwell
2024-03-22 14:32         ` Arnaldo Carvalho de Melo
2024-03-21 23:36   ` Stephen Rothwell
2024-03-21 23:40     ` arnaldo.melo
2024-03-21 23:48     ` Arnaldo Carvalho de Melo
2024-02-21 23:06 Stephen Rothwell
2024-02-23 19:50 ` Arnaldo Carvalho de Melo
2024-02-06 23:40 Stephen Rothwell
2024-02-07  0:02 ` Ian Rogers
2023-10-24 23:26 Stephen Rothwell
2023-10-25  0:34 ` Namhyung Kim
2023-05-29 23:05 Stephen Rothwell
2023-05-30  2:16 ` Ian Rogers
2022-08-30 22:34 Stephen Rothwell
2022-09-01  5:11 ` Anshuman Khandual
2022-09-06 19:05 ` Stephen Rothwell
2022-09-07  2:31   ` Anshuman Khandual
2022-09-07  3:00     ` Stephen Rothwell
2022-09-07  4:22       ` Anshuman Khandual
2022-09-08 15:21         ` Arnaldo Carvalho de Melo
2022-07-20 23:05 Stephen Rothwell
2022-07-21  2:35 ` Ian Rogers
2022-07-21  3:55   ` Stephen Rothwell
2022-07-21  5:33     ` Ian Rogers
2022-01-05 22:19 Stephen Rothwell
2022-01-07  8:58 ` kajoljain
2022-01-11 21:45   ` Stephen Rothwell
2022-01-11 22:01     ` Arnaldo Carvalho de Melo
2022-01-12  5:30       ` kajoljain
2022-01-12  6:16       ` Stephen Rothwell
2022-01-14 12:03       ` Michael Ellerman

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=ZBxTyLqkIaoVhIXU@kernel.org \
    --to=acme@kernel.org \
    --cc=arnaldo.melo@gmail.com \
    --cc=irogers@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=namhyung@kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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.