Re: scheduler performance regression since v6.11

[Peter Zijlstra <peterz@infradead.org>]

On Wed, May 21, 2025 at 04:02:46PM +0200, Dietmar Eggemann wrote:
> On 20/05/2025 21:38, Peter Zijlstra wrote:
> > On Tue, May 20, 2025 at 04:38:09PM +0200, Dietmar Eggemann wrote:
> > 
> >> 3840cbe24cf0 - sched: psi: fix bogus pressure spikes from aggregation race
> >>
> >> With CONFIG_PSI enabled we call cpu_clock(cpu) now multiple times (up to
> >> 4 times per task switch in my setup) in:
> >>
> >> __schedule() -> psi_sched_switch() -> psi_task_switch() ->
> >> psi_group_change().
> >>
> >> There seems to be another/other v6.12 related patch(es) later which
> >> cause(s) another 4% regression I yet have to discover.
> > 
> > Urgh, let me add this to the pile to look at. Thanks!
> 
> Not sure how expensive 'cpu_clock(cpu)' is on bare-metal.
> 
> But I also don't get why PSI needs per group 'now' values when we
> iterate over cgroup levels?

IIUC the read side does something like:

 real-read + guestimate(now, read-time);

And if the time-stamp is from before the write_seqcount_begin(), the
guestimate part goes side-ways.

My 'fix' is fairly simple straight forward brute force, but ideally this
whole thing gets some actual thinking done -- but my brain is fried from
staring at the wakeup path too long and I need to do simple things for a
few days ;-)