From: Namhyung Kim <namhyung@kernel.org>
To: Jan Polensky <japo@linux.ibm.com>
Cc: adrian.hunter@intel.com, irogers@google.com,
linux-perf-users@vger.kernel.org
Subject: Re: [RFC PATCH v1 1/1] perf test: Increase load in lock contention test on low-activity systems
Date: Wed, 16 Jul 2025 12:50:51 -0700 [thread overview]
Message-ID: <aHgCmxEZ_bcNeki-@google.com> (raw)
In-Reply-To: <20250709203809.3211178-1-japo@linux.ibm.com>
Hello,
On Wed, Jul 09, 2025 at 10:38:09PM +0200, Jan Polensky wrote:
> On low-activity systems, the 'kernel lock contention analysis test'
> often fails due to insufficient system load. To address this, the test
> now increases load by using multiple groups and threads in 'perf bench
> sched messaging', scaled to the number of available CPUs.
>
> Signed-off-by: Jan Polensky <japo@linux.ibm.com>
> ---
> tools/perf/tests/shell/lock_contention.sh | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/tests/shell/lock_contention.sh b/tools/perf/tests/shell/lock_contention.sh
> index 30d195d4c62f..e859e1503b5c 100755
> --- a/tools/perf/tests/shell/lock_contention.sh
> +++ b/tools/perf/tests/shell/lock_contention.sh
> @@ -44,7 +44,8 @@ check() {
> test_record()
> {
> echo "Testing perf lock record and perf lock contention"
> - perf lock record -o ${perfdata} -- perf bench sched messaging > /dev/null 2>&1
> + perf lock record -o ${perfdata} -- perf bench sched messaging \
> + --group "$(nproc)" --thread "$(nproc)" > /dev/null 2>&1
$ perf bench sched messaging -h
# Running 'sched/messaging' benchmark:
Usage: perf bench sched messaging <options>
-g, --group <n> Specify number of groups
-l, --nr_loops <n> Specify the number of loops to run (default: 100)
-p, --pipe Use pipe() instead of socketpair()
-t, --thread Be multi thread instead of multi process
The default value of --group option is 10 so it can be smaller on tiny
systems. Note that it'd create 20 tasks for each group (I don't think
we have an option to control this).
Also --thread option doesn't take an argument so the number will be
ignored.
More importantly, there are several instances of this workload.
Probably we want to change all of them by introducing a shell variable.
But I'm a bit afraid how much overhead it'd bring up.
Thanks,
Namhyung
> # the output goes to the stderr and we expect only 1 output (-E 1)
> perf lock contention -i ${perfdata} -E 1 -q 2> ${result}
> if [ "$(cat "${result}" | wc -l)" != "1" ]; then
> --
> 2.48.1
>
next prev parent reply other threads:[~2025-07-16 19:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-09 20:38 [RFC PATCH v1 1/1] perf test: Increase load in lock contention test on low-activity systems Jan Polensky
2025-07-10 5:47 ` Thomas Richter
2025-07-16 19:50 ` Namhyung Kim [this message]
2025-07-25 16:23 ` Jan Polensky
2025-07-26 5:35 ` Namhyung Kim
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=aHgCmxEZ_bcNeki-@google.com \
--to=namhyung@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=irogers@google.com \
--cc=japo@linux.ibm.com \
--cc=linux-perf-users@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).