linux-kernel - Re: scheduler performance regression since v6.11

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250523154031.GM39944@noisy.programming.kicks-ass.net>
Date: Fri, 23 May 2025 17:40:31 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Johannes Weiner <hannes@...xchg.org>
Cc: Dietmar Eggemann <dietmar.eggemann@....com>, Chris Mason <clm@...a.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	vschneid@...hat.com, Juri Lelli <juri.lelli@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: scheduler performance regression since v6.11

On Thu, May 22, 2025 at 11:00:35AM -0400, Johannes Weiner wrote:

> Ah right, since all the ancestor walks would ultimately end up at the
> system's seq anyway. And always have, really.
> 
> It does stretch the critical section, of course.

Right, with a cost proportional to the depth of the cgroup tree. So deep
trees will have it worse.

> I ran perf bench
> sched messaging to saturate all CPUs in state changes and then read a
> pressure file 1000x. This is on a 32-way machine:
> 
>      0.18%     +1.34%  [kernel.kallsyms]     [k] collect_percpu_times
> 
> and annotation shows it's indeed retrying on the seq-read a bit more.
> 
> But that seems well within tolerance, and obviously worth it assuming
> it fixes the cpu_clock() regression on the sched side.

Right, it appears it does :-)

> At that point, though, it probably makes sense to move seq out of
> psi_group_cpu altogether? More for clarity, really - it won't save
> much right away given that deliberate 2-cacheline-layout.
> 
> /* Serializes task state changes against aggregation runs */
> static DEFINE_PER_CPU(seqcount_t, psi_seq);

Sure, let me do that.

> Otherwise, the patch looks great to me. Thanks for including a couple
> of cleanups as well.

Yeah, mostly due to the back and forth -- my earlier ugly hack added
more tree iterations and me being lazy I didn't want to type all that
out :-)

Also, I've been migrating to using neovim with clangd language server,
and that doesn't much like the weird scheduler build setup, so I added
sufficient headers for the thing to 'compile' as a stand alone unit
(which is what clangd does).

I'll break out this patch and clean up all the sched bits to be clangd
clean -- I've been sitting on that patch long enough.

> Acked-by: Johannes Weiner <hannes@...xchg.org>

Thanks!