linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ravi Bangoria <ravi.bangoria@amd.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	andrii@kernel.org, Jiri Olsa <jolsa@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Ian Rogers <irogers@google.com>,
	linux-perf-users <linux-perf-users@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>
Subject: Re: [BUG] perf test: Regression because of d6e6286a12e7
Date: Wed, 12 Jul 2023 12:39:30 -0300	[thread overview]
Message-ID: <ZK7JMjN9LXTFEOvT@kernel.org> (raw)
In-Reply-To: <146e00be-98c8-873d-081f-252647b71b12@amd.com>

Em Wed, Jul 12, 2023 at 07:38:58PM +0530, Ravi Bangoria escreveu:
> On 11-Jul-23 3:06 AM, Andrii Nakryiko wrote:
> > On Sun, Jul 9, 2023 at 9:05 PM Ravi Bangoria <ravi.bangoria@amd.com> wrote:
> >> On 08-Jul-23 4:46 AM, Andrii Nakryiko wrote:
> >>> On Wed, Jul 5, 2023 at 9:39 PM Ravi Bangoria <ravi.bangoria@amd.com> wrote:
> >>>> I'm seeing perf test failure because of commit d6e6286a12e7 ("libbpf:
> >>>> disassociate section handler on explicit bpf_program__set_type() call").

> >>> Yep, this commit would reset catch-all custom handler, which perf is
> >>> setting. I've just sent a fix upstream ([0]). And once it lands, I'll
> >>> cut a v1.2.1 libbpf bugfix release with just this fix on top of v1.2.

> >>> Can you please double-check that this patch indeed fixes the issue for
> >>> you? I tried to do this locally, but for me perf test 42 fails both at
> >>> current bpf-next, with the above commit reverted, and with my fix
> >>> applied on top. So I can't be 100% sure.

> >>>   [0] https://patchwork.kernel.org/project/netdevbpf/patch/20230707231156.1711948-1-andrii@kernel.org/

> >> Thanks. A quick test seems to be working fine.

> > Alright, thanks for confirming! I've just released v1.2.1 bug fix
> > release with just this fix on top of v1.2.

> > Thanks for reporting!

> > But given v1.2 was cut on May 1st, and the offending commit landed
> > some time late March, I wonder how did this slip through the cracks
> > and go unreported for so long? Is there something we can do to catch
> > these perf-only regressions a bit sooner?

> I guess it got slipped because that patch went in via bpf tree. Would
> it be possible to run bpf related perf tests at the time of applying
> libbpf patches? Arnaldo might have better ideas :)

Right, perhaps the libbpf CI could try building perf, preferably with
BUILD_BPF_SKEL=1, to enable these tools:

[acme@nine linux]$ ls -la tools/perf/util/bpf_skel/*.bpf.*
-rw-r--r--. 1 acme acme  5581 Jul  7 12:38 tools/perf/util/bpf_skel/bperf_cgroup.bpf.c
-rw-r--r--. 1 acme acme  1764 Jul  7 12:38 tools/perf/util/bpf_skel/bperf_follower.bpf.c
-rw-r--r--. 1 acme acme  1438 Jul  7 12:38 tools/perf/util/bpf_skel/bperf_leader.bpf.c
-rw-r--r--. 1 acme acme  2290 Jul  7 12:38 tools/perf/util/bpf_skel/bpf_prog_profiler.bpf.c
-rw-r--r--. 1 acme acme  2164 Jul  7 12:38 tools/perf/util/bpf_skel/func_latency.bpf.c
-rw-r--r--. 1 acme acme  9017 Jul  7 12:38 tools/perf/util/bpf_skel/kwork_trace.bpf.c
-rw-r--r--. 1 acme acme 10147 Jul 12 11:49 tools/perf/util/bpf_skel/lock_contention.bpf.c
-rw-r--r--. 1 acme acme  6109 Jul  7 12:38 tools/perf/util/bpf_skel/off_cpu.bpf.c
-rw-r--r--. 1 acme acme  4932 Jul  7 12:38 tools/perf/util/bpf_skel/sample_filter.bpf.c
[acme@nine linux]$

There are 'perf test' entries for the BPF support in perf that is pre
libbpf skel functionality above and as well some for the libbpf based
skel features, such as:

[root@quaco ~]# perf test -vvv contention
 87: kernel lock contention analysis test                            :
--- start ---
test child forked, pid 213314
Testing perf lock record and perf lock contention
Testing perf lock contention --use-bpf
Testing perf lock record and perf lock contention at the same time
Testing perf lock contention --threads
Testing perf lock contention --lock-addr
Testing perf lock contention --type-filter (w/ spinlock)
Testing perf lock contention --lock-filter (w/ tasklist_lock)
Testing perf lock contention --callstack-filter (w/ unix_stream)
Testing perf lock contention --callstack-filter with task aggregation
Testing perf lock contention CSV output
test child finished with 0
---- end ----
kernel lock contention analysis test: Ok
[root@quaco ~]#

We could perhaps add support for some kind of tags to the tests, to
help run just the ones that use bpf and then you could use:

 # perf test --uses bpf

At first we would just add this tag, then we would use it for other
stuff as the need arises to run just a subset of the tests.

But for now you could start perhaps with:

[root@quaco ~]# perf test LLVM ; perf test "BPF " ; perf test "lock contention"
 40: LLVM search and compile                                         :
 40.1: Basic BPF llvm compile                                        : Ok
 40: LLVM search and compile                                         :
 40.1: Basic BPF llvm compile                                        : Ok
 40.3: Compile source for BPF prologue generation                    : Ok
 40.4: Compile source for BPF relocation                             : Ok
 42: BPF filter                                                      :
 42.1: Basic BPF filtering                                           : Ok
 42.2: BPF pinning                                                   : Ok
 42.3: BPF prologue generation                                       : FAILED!
 87: kernel lock contention analysis test                            : Ok
[root@quaco ~]#

- Arnaldo

  reply	other threads:[~2023-07-12 15:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-06  4:37 [BUG] perf test: Regression because of d6e6286a12e7 Ravi Bangoria
2023-07-07 23:16 ` Andrii Nakryiko
2023-07-10  4:03   ` Ravi Bangoria
2023-07-10 21:36     ` Andrii Nakryiko
2023-07-12 14:08       ` Ravi Bangoria
2023-07-12 15:39         ` Arnaldo Carvalho de Melo [this message]
2023-07-12 18:20           ` Alexei Starovoitov
2023-07-13 20:57             ` Arnaldo Carvalho de Melo
2023-07-14 18:15               ` Mykola Lysenko
     [not found]                 ` <SA1PR15MB46099ABDC08009096019B5B4CBF7A@SA1PR15MB4609.namprd15.prod.outlook.com>
2023-09-14 21:54                   ` Ian Rogers
2023-09-17  9:22                   ` Arnaldo Carvalho de Melo

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=ZK7JMjN9LXTFEOvT@kernel.org \
    --to=acme@kernel.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=namhyung@kernel.org \
    --cc=ravi.bangoria@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).