All of lore.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 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.