Re: [RFC PATCH v1 1/1] perf test: Increase load in lock contention test on low-activity systems

[Namhyung Kim <namhyung@kernel.org>]

On Fri, Jul 25, 2025 at 06:23:17PM +0200, Jan Polensky wrote:
> Hello Namhyung,
> On Wed, Jul 16, 2025 at 12:50:51PM -0700, Namhyung Kim wrote:
> > 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>
> > > ---
> [skip]
> >
> > More importantly, there are several instances of this workload.
> > Probably we want to change all of them by introducing a shell variable.
> You're right — introducing a shell variable makes sense, especially since
> there are 13 identical calls. However, I’m slightly concerned that this
> might reduce readability. We might also consider an alternative solution
> to avoid this.

We already have similar code in other places like record.sh.

Thanks,
Namhyung


> > But I'm a bit afraid how much overhead it'd bring up.
> Indeed, using the --group parameter on large systems can lead to issues.
> For example:
> 
>     [root@localhost perf]# ./perf stat -- perf bench sched messaging --group $(nproc) --thread
>     # Running 'sched/messaging' benchmark:
>     perf: socketpair(): Too many open files
> 
> To avoid this, I suggest following the approach proposed by Thomas
> Richter (tmricht@linux.ibm.com), using the -p (pipe) mode instead:
> 
>     perf bench sched messaging -p
> 
> The pipe-based solution generates sufficient load and lock contention for
> the test, while avoiding the use of sockets and their associated file
> descriptor limits.
> 
> I’ll incorporate these changes and send the next version shortly.
> 
> Thanks again for your feedback – it's much appreciated.
> 
> Best regards,
> Jan