Re: [PATCH v5 07/10] perf sched stats: Add support for live mode

[Swapnil Sapkal]

Hi James,

On 30-03-2026 20:05, James Clark wrote:
> On 10/03/2026 10:08 am, Swapnil Sapkal wrote:
> > Hi Ian,
> >
> > Sorry for the delay.
> >
> > On 04-03-2026 00:17, Ian Rogers wrote:
> > > On Mon, Jan 19, 2026 at 10:02 AM Swapnil Sapkal
> > > <swapnil.sapkal@xxxxxxx> wrote:
> > > [ snip ]
> > > > +       /* wait for signal */
> > > > +       pause();
> > >
> > > I'm seeing the perf sched stats test hang here, requiring me to kill
> > > the perf process started by the test. It is unclear what signal is
> > > being waited upon, but is there a race condition where the signal
> > > could have occurred before the pause? Should the pause at least be
> > > conditional on that happening? Given that a race condition would exist
> > > even with a test, would it be better to use a condition variable?
> >
> > I am able to reproduce the issue. There are other places also where the
> > same issue can be reproduced. (e.g. with `perf lock contention -b`)
> >
> > I will propose a fix.
> >
> > > Thanks,
> > > Ian
> > --
> > Thanks and Regards,
> > Swapnil
>
> Hi Swapnil,
>
> I'm also seeing the same issue, did you come up with a fix yet? I think
> checking the finish condition in a loop would work as long as it's
> sleep() instead of pause(). Or if you want to use pause() you have to
> mask the signals before launching and then do a sigsuspend() to unmask
> and pause atomically.
>
> I was able to reproduce it every time by using the runs per test option:
>
>    $ perf test -vvv -r 10 "perf sched stats tests"

I sent the fix for here.

https://lore.kernel.org/all/20260401064114.141066-1-swapnil.sapkal@xxxxxxx/. 


> Running multiple in parallel also showed another issue because the test
> writes to and deletes perf.data in the current working directory.
> Usually the tests do mktmp somewhere so they have a unique output dir to
> not conflict with other tests.

I will work on this issue.

> Thanks
> James
--
Thanks and Regards,
Swapnil