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

[Joseph Salisbury]

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

After the commit, both paths use:

  idle_call_stop_or_retain_tick(got_tick)

Here, got_tick is true if the CPU was woken from the previous idle-loop 
iteration by the scheduler tick, and false otherwise. On this 
workload/platform combination, using that previous wakeup source to 
decide whether to stop or retain the tick appears to change NOHZ 
behavior enough to regress this wakeup-heavy threaded workload.


Do you have any thoughts on whether this is an expected tradeoff of the 
new heuristic, or whether the special cases need a narrower condition?  
For our stable kernels, the immediate candidate fix is to revert the 
backport, but before doing that I wanted to ask whether upstream would 
prefer a targeted adjustment.

I can collect additional data if useful, for example cpuidle 
driver/state information, timer interrupt counts, idle residency, perf 
stat, or scheduler trace data from the affected OCI shapes.

#regzbot introduced: f4c31b07b136839e0fb3026f8a5b6543e3b14d2f


Thanks,

Joe