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

[Swapnil Sapkal <swapnil.sapkal@amd.com>]

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@amd.com> 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@amd.com/. 


> 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