Re: [PATCH v3 0/7] sched: Flatten the pick

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Aug 18, 2026 at 10:04:57AM +0100, Szabina Korbai wrote:
> On Mon, 2026-08-17 at 22:05 +0530, K Prateek Nayak wrote:
> > Hello Szabina,
> > 
> > On 8/17/2026 9:35 PM, Szabina Korbai wrote:
> > > Hello Peter,
> > > 
> > > We ran the same benchmarks (schbench, sysbench, hackbench) as
> > > Shubhang
> > > has on s390 on an LPAR running fedora 43 with 32 vCPUs.
> > > 
> > > We ran the benchmarks for each of the cgroup modes, and for the
> > > baseline, we chose the commit prior to the patches (f666241e6bd5 -
> > > sched/fair: Unify cfs_rq throttling via account_cfs_rq_runtime() ).
> > > 
> > > We have also tried running stress-ng in parallel with the
> > > benchmarks
> > > (set to generate 50% or 90% utilization for each vCPU).
> > > 
> > > Compared to simply running the benchmarks on their own, this has
> > > revealed some performance trade-offs that the move to a single
> > > runqueue
> > > can introduce.
> > 
> > Are you using tip:sched/core at commit 68e3748781 ("sched/fair: Fix
> > flat
> > hierarchy") for the flat_cg numbers or did you checkout at
> > 85570f10a4c6
> > ("sched/eevdf: Move to a single runqueue")?
> > 
> > There are a couple fixes for vruntime update and Vincent's
> > optimizations
> > for preemption bits which might make a difference to the overall
> > results.
> 
> 
> Hi Prateek,
> 
> thank you, that's a good call. I did checkout at "Move to a single
> runqueue". Let me try it with the fix included, see how the results are
> affected.

I've not yet managed to digest your various benchmark results, but also
double check that patch 6/7 from this series is not to 'blame' for the
some of the changes.

The 0day robot fingered that patch for at least one issue.

In that case the benchmark threads ended up 'heavier' than before, which
resulted in less preemptions. Probably ksoftirqd getting ran less and
causing a regression in network throughput for that thing.

I did suggest trying to change the slice of ksoftirqd down, such that it
might be ran more readily, but I'm not sure that ever got tried.