[PATCH v1] perf tests: Restore -p flag to lock contention test

[PATCH v1] perf tests: Restore -p flag to lock contention test

[Ian Rogers]

Commit ae42a2a2a3ae ("perf tests: Speed up lock contention analysis shell test")
in linux-next heavily optimized the test runtimes by switching the workload from
the default of 10 process groups down to 1 (`perf bench sched messaging -g 1`).

However, this change inadvertently dropped the original `-p` flag, causing the
benchmark to default to `socketpair()` instead of `pipe()`. While `socketpair()`
still generates some lock events on x86, it fails to trigger enough samples on
architectures like s390, causing the test suite to fail due to lack of captured
data.

Restore the omitted `-p` pipe flag. The test retains the massive speedups
achieved through the `-g 1` scaling, while producing a massive density of lock
events across all architectures to fully satisfy the BPF trace filtering logic.

Fixes: ae42a2a2a3ae ("perf tests: Speed up lock contention analysis shell test")
Signed-off-by: Ian Rogers <irogers@google.com>
Assisted-by: Antigravity:gemini-3.1-pro
---
 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 ba598370be73..5df9a0cd48a3 100755
--- a/tools/perf/tests/shell/lock_contention.sh
+++ b/tools/perf/tests/shell/lock_contention.sh
@@ -11,7 +11,8 @@ errout=$(mktemp /tmp/__perf_test.errout.XXXXX)
 
 # Workload to generate lock contention.
 # Using 1 group (-g 1) keeps runtime low while generating sufficient lock events.
-msg_workload="perf bench sched messaging -g 1"
+# We include -p (pipes) because socketpairs don't generate enough lock events on s390.
+msg_workload="perf bench sched messaging -g 1 -p"
 
 cleanup() {
 	rm -f ${perfdata}
-- 
2.55.0.795.g602f6c329a-goog

Re: [PATCH v1] perf tests: Restore -p flag to lock contention test

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Adding the `-p` (pipe) flag to the global workload unconditionally disables the stack filter tests.
--

--- Patch [1]: [PATCH v1] perf tests: Restore -p flag to lock contention test ---
commit b4bb7054950dea7123c601308622ddcd596c94cf
Author: Ian Rogers <irogers@google.com>

perf tests: Restore -p flag to lock contention test

This commit restores the -p flag to the perf bench sched messaging workload
used by the lock contention test. By defaulting to pipes instead of
socketpairs, it ensures architectures like s390 generate sufficient lock
events for the BPF trace filtering logic to pass.

> diff --git a/tools/perf/tests/shell/lock_contention.sh b/tools/perf/tests/shell/lock_contention.sh
> index ba598370be738..5df9a0cd48a34 100755
> --- a/tools/perf/tests/shell/lock_contention.sh
> +++ b/tools/perf/tests/shell/lock_contention.sh
> @@ -11,7 +11,8 @@ errout=$(mktemp /tmp/__perf_test.errout.XXXXX)
>  
>  # Workload to generate lock contention.
>  # Using 1 group (-g 1) keeps runtime low while generating sufficient lock events.
> -msg_workload="perf bench sched messaging -g 1"
> +# We include -p (pipes) because socketpairs don't generate enough lock events on s390.
> +msg_workload="perf bench sched messaging -g 1 -p"

[Severity: Medium]
Will adding the -p flag cause test_stack_filter() and 
test_aggr_task_stack_filter() to unconditionally skip?

These tests explicitly verify filtering behavior by searching for unix_stream 
locks in tools/perf/tests/shell/lock_contention.sh:

test_stack_filter()
{
	echo "Testing perf lock contention --callstack-filter (w/ unix_stream)"
	perf lock contention -i ${perfdata} -v -q 2> ${result}
	if [ "$(grep -c unix_stream "${result}")" = "0" ]; then
		echo "[Skip] Could not find 'unix_stream'"
		return
	fi

Since pipes use pipe locks instead of AF_UNIX stream socket locks 
(unix_stream), the shared perfdata profile will no longer contain these locks. 

Does this mean we lose test suite coverage for the --callstack-filter option 
across all architectures because the grep will always return 0?

>  
>  cleanup() {
>  	rm -f ${perfdata}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708175311.858850-1-irogers@google.com?part=1

Re: [PATCH v1] perf tests: Restore -p flag to lock contention test

[Namhyung Kim]

On Wed, Jul 08, 2026 at 05:59:47PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Adding the `-p` (pipe) flag to the global workload unconditionally disables the stack filter tests.
> --
> 
> --- Patch [1]: [PATCH v1] perf tests: Restore -p flag to lock contention test ---
> commit b4bb7054950dea7123c601308622ddcd596c94cf
> Author: Ian Rogers <irogers@google.com>
> 
> perf tests: Restore -p flag to lock contention test
> 
> This commit restores the -p flag to the perf bench sched messaging workload
> used by the lock contention test. By defaulting to pipes instead of
> socketpairs, it ensures architectures like s390 generate sufficient lock
> events for the BPF trace filtering logic to pass.
> 
> > diff --git a/tools/perf/tests/shell/lock_contention.sh b/tools/perf/tests/shell/lock_contention.sh
> > index ba598370be738..5df9a0cd48a34 100755
> > --- a/tools/perf/tests/shell/lock_contention.sh
> > +++ b/tools/perf/tests/shell/lock_contention.sh
> > @@ -11,7 +11,8 @@ errout=$(mktemp /tmp/__perf_test.errout.XXXXX)
> >  
> >  # Workload to generate lock contention.
> >  # Using 1 group (-g 1) keeps runtime low while generating sufficient lock events.
> > -msg_workload="perf bench sched messaging -g 1"
> > +# We include -p (pipes) because socketpairs don't generate enough lock events on s390.
> > +msg_workload="perf bench sched messaging -g 1 -p"
> 
> [Severity: Medium]
> Will adding the -p flag cause test_stack_filter() and 
> test_aggr_task_stack_filter() to unconditionally skip?
> 
> These tests explicitly verify filtering behavior by searching for unix_stream 
> locks in tools/perf/tests/shell/lock_contention.sh:
> 
> test_stack_filter()
> {
> 	echo "Testing perf lock contention --callstack-filter (w/ unix_stream)"
> 	perf lock contention -i ${perfdata} -v -q 2> ${result}
> 	if [ "$(grep -c unix_stream "${result}")" = "0" ]; then
> 		echo "[Skip] Could not find 'unix_stream'"
> 		return
> 	fi
> 
> Since pipes use pipe locks instead of AF_UNIX stream socket locks 
> (unix_stream), the shared perfdata profile will no longer contain these locks. 
> 
> Does this mean we lose test suite coverage for the --callstack-filter option 
> across all architectures because the grep will always return 0?

I think it's a valid concern but it didn't come from this change.
Maybe we need to check different symbols like "pipe_".

Thanks,
Namhyung

Re: [PATCH v1] perf tests: Restore -p flag to lock contention test

[Thomas Richter]

On 7/8/26 19:53, Ian Rogers wrote:
> Commit ae42a2a2a3ae ("perf tests: Speed up lock contention analysis shell test")
> in linux-next heavily optimized the test runtimes by switching the workload from
> the default of 10 process groups down to 1 (`perf bench sched messaging -g 1`).
> 
> However, this change inadvertently dropped the original `-p` flag, causing the
> benchmark to default to `socketpair()` instead of `pipe()`. While `socketpair()`
> still generates some lock events on x86, it fails to trigger enough samples on
> architectures like s390, causing the test suite to fail due to lack of captured
> data.
> 
> Restore the omitted `-p` pipe flag. The test retains the massive speedups
> achieved through the `-g 1` scaling, while producing a massive density of lock
> events across all architectures to fully satisfy the BPF trace filtering logic.
> 
> Fixes: ae42a2a2a3ae ("perf tests: Speed up lock contention analysis shell test")
> Signed-off-by: Ian Rogers <irogers@google.com>
> Assisted-by: Antigravity:gemini-3.1-pro
> ---
>  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 ba598370be73..5df9a0cd48a3 100755
> --- a/tools/perf/tests/shell/lock_contention.sh
> +++ b/tools/perf/tests/shell/lock_contention.sh
> @@ -11,7 +11,8 @@ errout=$(mktemp /tmp/__perf_test.errout.XXXXX)
>  
>  # Workload to generate lock contention.
>  # Using 1 group (-g 1) keeps runtime low while generating sufficient lock events.
> -msg_workload="perf bench sched messaging -g 1"
> +# We include -p (pipes) because socketpairs don't generate enough lock events on s390.
> +msg_workload="perf bench sched messaging -g 1 -p"
>  
>  cleanup() {
>  	rm -f ${perfdata}

Tested-by: Thomas Richter <tmricht@linux.ibm.com>

Thanks a lot

-- 
Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany
--
IBM Deutschland Research & Development GmbH

Vorsitzender des Aufsichtsrats: Wolfgang Wendt

Geschäftsführung: David Faller

Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294

Re: [PATCH v1] perf tests: Restore -p flag to lock contention test

[Namhyung Kim]

On Wed, 08 Jul 2026 10:53:11 -0700, Ian Rogers wrote:
> Commit ae42a2a2a3ae ("perf tests: Speed up lock contention analysis shell test")
> in linux-next heavily optimized the test runtimes by switching the workload from
> the default of 10 process groups down to 1 (`perf bench sched messaging -g 1`).
> 
> However, this change inadvertently dropped the original `-p` flag, causing the
> benchmark to default to `socketpair()` instead of `pipe()`. While `socketpair()`
> still generates some lock events on x86, it fails to trigger enough samples on
> architectures like s390, causing the test suite to fail due to lack of captured
> data.
> 
> [...]
Applied to perf-tools-next, thanks!

Best regards,
Namhyung