Re: [REGRESSION] sched/idle: Sysbench threads regression after f4c31b07b136

On 7/2/26 19:47, Rafael J. Wysocki (Intel) wrote:
> Hi,
> 
> On Thu, Jul 2, 2026 at 6:30 PM Joseph Salisbury
> <[email protected]> wrote:
>>
>> Hi Rafael,
>>
>> We are seeing a reproducible MySQL Sysbench threads regression.  A
>> bisect indicated the following commit as the first bad commit:
>> f4c31b07b136 ("sched: idle: Consolidate the handling of two special cases")
>>
>> The regression was found in Oracle kernel performance testing on OCI VM
>> shapes:
>>
>> VM Details:
>> * VM.Standard2.1:
>>        x86 OCI VM shape, 1 OCPU / 2 hardware threads, about 14.5 GB RAM
>>
>>   * VM.Standard.A1.Flex.2:
>>        Arm/Ampere A1 flexible VM shape, 2 vCPU threads, about 10.9 GB RAM
>>
>>
>> The ResultsDB runs show the regression in the Sysbench threads metric:
>>
>>    - VM.Standard2.1:       333 -> 236  (-29.1%)
>>    - VM.Standard.A1.Flex.2: 1286 -> 1152 (-10.4%)
>>
>> A test kernel was built with f4c31b07b136 reverted and the performance
>> regression was recovered.
>>
>>  From the code, it is possible the regression is due to the new
>> previous-wakeup heuristic in the special idle cases.  Before the commit:
>>
>>    - no cpuidle driver:
>>        tick_nohz_idle_stop_tick()
>>        default_idle_call()
>>
>>    - one idle state:
>>        tick_nohz_idle_retain_tick()
>>        cpuidle state 0
> 
> I think that this is your case and the tick stops for you sometimes
> now while it had never stopped before.
> 
> Can you confirm?
> 
> Overall, it would be good to know the idle state lists for both the VM
> and the host.
> 
+1, but also which HZ are you using?
Both systems reported have 2 logical CPUs then? Were higher core counts also
tested and how does it affect them?