Re: scheduler performance regression since v6.11

[Chris Mason <clm@meta.com>]

On 5/12/25 2:08 PM, Peter Zijlstra wrote:
> On Fri, May 09, 2025 at 09:49:55PM +0200, Peter Zijlstra wrote:
>> 152 729288bc6856 kernel/sched: Fix util_est accounting for DELAY_DEQUEUE
>> 	average rps: 1936829.47
>> 	average rps: 1950715.10
>>
>> 153 84d265281d6c sched/pelt: Use rq_clock_task() for hw_pressure
>> 	average rps: 2176857.32
>> 	average rps: 2223004.23
> 
> So, a little more data on this.
> 
> The result appears stable, but reverting 729288bc6856 on master does not
> seem to cure things.

729288bc6856 is in that section of commits where the regression was ~1/2
as bad.  (bad: 1.8M, good: 2M, middle ground: 1.9M) I get the same RPS
with and without it.

I called it "good" in my bisect run, but I'll take a second pass through
those potential suspects and see if the bad really starts there.

> 
> OTOH, switching to performance governor completely cures things here.
> 
> My machine defaults to schedutil governor.
> 
> Chris, can you confirm -- or did we manage to find different issues?

My repro script sets to performance w/turbo on as step one.  I didn't
turbostat my way to making sure both sides were actually running at the
same frequency, but I'll check that too.

-chris