Re: [REGRESSION] [PATCH v3 7/7] sched/eevdf: Move to a single runqueue

[Chen Yu <yu.c.chen@intel.com>]

Hi Mike, Prateek,

On Thu, Sep 24, 2026 at 10:19:35AM +0200, Mike Galbraith wrote:
> On Thu, 2026-09-24 at 00:48 +0800, Chen Yu wrote:
> > 
> > Would disabling WA_WEIGHT help? I happened to find that this workaround works
> > for me to restore netperf performance (though it is a throughput score rather
> > than a latency one), it seems that task_h_load() becomes much
> > larger(also on sched/task_h_load):
> > echo NO_WA_WEIGHT > /sys/kernel/debug/sched/features
> > https://lore.kernel.org/lkml/aoxah90s0bQ4tcUW@three-body/ 
> 
> A long while back, I caught WA_WEIGHT causing firefox's event thread
> pool to stack on a single CPU.  

I just realized that what I suggested - disabling WA_WEIGHT - does the opposite.
Actually, WA_WEIGHT does help in the netperf scenario. Disabling WA_WEIGHT makes
the performance of both "smp" and "concur" modes drop to the same poor level, which
makes it look like the regression disappears, but actually it does not.

According to my test last week, stacking the waker and wakee on the same CPU brings
a big improvement on my machine, iff the memory bandwidth is saturated. By comparison,
if the memory bandwidth is low, stacking the wakee on top of the waker causes harm.

The machine I used has 2 NUMA nodes; each node has 96 cores, and these 96 cores share
L3, while every 4 cores share L2. The L2 miss rate is much lower if the waker and wakee
are on the same CPU than if the wakee is put on other idle CPUs in the same L2 domain.
Yes, the same L2 - which goes against intuition. How could the L2 miss rate rise even
if the waker and wakee are in the same L2 domain?

I guess this is because stacking the waker and wakee on the same CPU and letting them
run alternately would be the most efficient way to consume the data without evicting
L2 cache lines too much, when the memory bandwidth is saturated.

> In that particular case, the victims
> (32 of 'em in 8 rq box!) did nothing but go back to sleep, so no real
> harm was done. However, I also measured modest real stacking impact, so
> gave task_h_load() a floor on GP.
> 
> Perhaps weightless burst stacking is a bigger deal for some than it was
> here?  That firefox event thread burst showed potential.
>  

It depends on the workload and the memory bandwidth of the system, I suppose. 
If the workload is a producer-consumer type, and the system is under memory bandwidth
pressure, stacking the producer and consumer would bring good data locality - in terms
of L2 locality, per my test.

In summary, the "regression" of flat cgroup task-pick on netperf (or, producer-consumer
type workloads) seems to be the expected consequence. Maybe we need to make WA_WEIGHT
consider more factors here.

I'll collect more data and provide the information later.

thanks,
Chenyu
> 	-Mike