From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
peterz@infradead.org, mingo@redhat.com, mark.rutland@arm.com,
alexander.shishkin@linux.intel.com, jolsa@kernel.org,
namhyung@kernel.org, elver@google.com,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tools/perf: add breakpoint benchmarks
Date: Wed, 11 May 2022 15:16:58 -0300 [thread overview]
Message-ID: <Ynv9mm4w9YfEU5j8@kernel.org> (raw)
In-Reply-To: <Ynv7gkbBVd9dlJRh@kernel.org>
Em Wed, May 11, 2022 at 03:08:02PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, May 11, 2022 at 08:34:58AM -0700, Ian Rogers escreveu:
> > On Thu, May 5, 2022 at 8:58 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > >
> > > Add 2 benchmarks:
> > > 1. Performance of thread creation/exiting in presence of breakpoints.
> > > 2. Performance of breakpoint modification in presence of threads.
> > >
> > > The benchmarks capture use cases that we are interested in:
> > > using inheritable breakpoints in large highly-threaded applications.
> > > The benchmarks show significant slowdown imposed by breakpoints
> > > (even when they don't fire).
> > >
> > > Testing on Intel 8173M with 112 HW threads show:
> > >
> > > perf bench --repeat=56 breakpoint thread --breakpoints=0 --parallelism=56 --threads=20
> > > 78.675000 usecs/op
> > > perf bench --repeat=56 breakpoint thread --breakpoints=4 --parallelism=56 --threads=20
> > > 12967.135714 usecs/op
> > > That's 165x slowdown due to presence of the breakpoints.
> > >
> > > perf bench --repeat=20000 breakpoint enable --passive=0 --active=0
> > > 1.433250 usecs/op
> > > perf bench --repeat=20000 breakpoint enable --passive=224 --active=0
> > > 585.318400 usecs/op
> > > perf bench --repeat=20000 breakpoint enable --passive=0 --active=111
> > > 635.953000 usecs/op
> > > That's 408x and 444x slowdown due to presence of threads.
> > >
> > > Profiles show some overhead in toggle_bp_slot,
> > > but also very high contention:
> > >
> > > 90.83% breakpoint-thre [kernel.kallsyms] [k] osq_lock
> > > 4.69% breakpoint-thre [kernel.kallsyms] [k] mutex_spin_on_owner
> > > 2.06% breakpoint-thre [kernel.kallsyms] [k] __reserve_bp_slot
> > > 2.04% breakpoint-thre [kernel.kallsyms] [k] toggle_bp_slot
> > >
> > > 79.01% breakpoint-enab [kernel.kallsyms] [k] smp_call_function_single
> > > 9.94% breakpoint-enab [kernel.kallsyms] [k] llist_add_batch
> > > 5.70% breakpoint-enab [kernel.kallsyms] [k] _raw_spin_lock_irq
> > > 1.84% breakpoint-enab [kernel.kallsyms] [k] event_function_call
> > > 1.12% breakpoint-enab [kernel.kallsyms] [k] send_call_function_single_ipi
> > > 0.37% breakpoint-enab [kernel.kallsyms] [k] generic_exec_single
> > > 0.24% breakpoint-enab [kernel.kallsyms] [k] __perf_event_disable
> > > 0.20% breakpoint-enab [kernel.kallsyms] [k] _perf_event_enable
> > > 0.18% breakpoint-enab [kernel.kallsyms] [k] toggle_bp_slot
> > >
> > > Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
> >
> > Acked-by: Ian Rogers <irogers@google.com>
>
> Thanks, applied.
But I'll add some error checks, etc, running as !root, in a toolbox in
Fedora Silverblue produces:
⬢[acme@toolbox perf]$ perf bench breakpoint all
# Running breakpoint/thread benchmark...
# Created/joined 10 threads with 1 breakpoints and 1 parallelism
Total time: 0.000 [sec]
54.600000 usecs/op
54.600000 usecs/op/cpu
# Running breakpoint/enable benchmark...
# Enabled/disabled breakpoint 10 time with 0 passive and 0 active threads
Total time: 0.000 [sec]
1.100000 usecs/op
⬢[acme@toolbox perf]$
⬢[acme@toolbox perf]$ perf bench --repeat=20000 breakpoint enable --passive=224 --active=0
# Running 'breakpoint/enable' benchmark:
# Enabled/disabled breakpoint 20000 time with 224 passive and 0 active threads
Total time: 8.933 [sec]
446.674950 usecs/op
⬢[acme@toolbox perf]$
$ grep -m1 "model name" /proc/cpuinfo
model name : AMD Ryzen 9 5950X 16-Core Processor
Diff:
diff --git a/tools/perf/bench/breakpoint.c b/tools/perf/bench/breakpoint.c
index 56936fea246d73c2..d2c074bba06a3d1f 100644
--- a/tools/perf/bench/breakpoint.c
+++ b/tools/perf/bench/breakpoint.c
@@ -83,6 +83,9 @@ static void *breakpoint_thread(void *arg)
pthread_t *threads;
threads = calloc(thread_params.nthreads, sizeof(threads[0]));
+ if (!threads)
+ exit((perror("calloc"), EXIT_FAILURE));
+
while (__atomic_fetch_sub(repeat, 1, __ATOMIC_RELAXED) > 0) {
done = 0;
for (i = 0; i < thread_params.nthreads; i++) {
@@ -114,6 +117,9 @@ int bench_breakpoint_thread(int argc, const char **argv)
}
breakpoints = calloc(thread_params.nbreakpoints, sizeof(breakpoints[0]));
parallel = calloc(thread_params.nparallel, sizeof(parallel[0]));
+ if (!breakpoints || !parallel)
+ exit((perror("calloc"), EXIT_FAILURE));
+
for (i = 0; i < thread_params.nbreakpoints; i++) {
breakpoints[i].fd = breakpoint_setup(&breakpoints[i].watched);
if (breakpoints[i].fd == -1)
@@ -194,6 +200,9 @@ int bench_breakpoint_enable(int argc, const char **argv)
exit((perror("perf_event_open"), EXIT_FAILURE));
nthreads = enable_params.npassive + enable_params.nactive;
threads = calloc(nthreads, sizeof(threads[0]));
+ if (!threads)
+ exit((perror("calloc"), EXIT_FAILURE));
+
for (i = 0; i < nthreads; i++) {
if (pthread_create(&threads[i], NULL,
i < enable_params.npassive ? passive_thread : active_thread, &done))
next prev parent reply other threads:[~2022-05-11 18:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-05 15:57 [PATCH] tools/perf: add breakpoint benchmarks Dmitry Vyukov
2022-05-06 7:58 ` Dmitry Vyukov
2022-05-11 15:34 ` Ian Rogers
2022-05-11 18:08 ` Arnaldo Carvalho de Melo
2022-05-11 18:16 ` Arnaldo Carvalho de Melo [this message]
2022-05-12 8:03 ` Dmitry Vyukov
2022-05-12 8:04 ` Dmitry Vyukov
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=Ynv9mm4w9YfEU5j8@kernel.org \
--to=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/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