public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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))

  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