Re: [PATCH v4 11/13] perf tests: Speed up lock contention analysis shell test

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch omits the `-p` (pipe) flag from the `msg_workload` variable, directly contradicting the commit message and implicitly changing the test's IPC mechanism.
--

commit a71dd68d0ef76f3ef77f506f4808d8fbc7e5fa36
Author: Ian Rogers <irogers@google.com>

perf tests: Speed up lock contention analysis shell test

This commit optimizes the lock contention analysis test suite by introducing
a scaled-down messaging benchmark workload. It reduces the number of process
groups from the default to 1, aiming to decrease test runtime and trace
overhead while still exercising BPF filters.

> diff --git a/tools/perf/tests/shell/lock_contention.sh b/tools/perf/tests/shell/lock_contention.sh
> --- a/tools/perf/tests/shell/lock_contention.sh
> +++ b/tools/perf/tests/shell/lock_contention.sh
> @@ -9,6 +9,10 @@ perfdata=$(mktemp /tmp/__perf_test.perf.data.XXXXX)
>  result=$(mktemp /tmp/__perf_test.result.XXXXX)
>  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"

[Severity: Medium]
Does this assignment unintentionally omit the -p flag?

The commit message explicitly states the optimization uses the workload
"perf bench sched messaging -g 1 -p", but the flag is missing here.

According to the sched-messaging benchmark implementation, omitting the
pipe flag causes it to default to using Unix domain sockets instead of
pipes.

While the test still passes because socketpairs coincidentally generate
the unix_stream lock events that test_stack_filter looks for, this silently
alters the kernel IPC mechanisms and locking paths being stressed.

[ ... ]

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