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

[Peter Zijlstra]

On Mon, Aug 24, 2026 at 10:51:51PM +0800, Chen Yu wrote:
> TL;DR,
> The decision made by wake_affine_weight() seems to be affected by the increased
> weight of the wakee under concur mode. As a result, wake_affine_weight() became less
> likely to select this_cpu. This reduced preference for this_cpu leads to a higher
> L2 miss rate on this platform, and consequently lower throughput.
> 
> Test summary:
> 
> | Config | Throughput (Mbps) | **L2 miss%** | **LLC miss%** |
> | smp + WA_WEIGHT | **470249** | **19.37%** | 60.08% |
> | smp + NO_WA_WEIGHT | 305360 | 32.67% | 60.46% |
> | concur + WA_WEIGHT | 338770 | 31.45% | 62.85% |
> | concur + NO_WA_WEIGHT | 259358 | 36.24% | 61.95% |

(I'm thinking it would've been easier to read if all those '|' were
properly aligned?)

> We can see if WA_WEIGHT is disabled in smp mode, the performance drops to concur. One
> possible reason is that task_h_load(p) returns a very small value in smp mode(just the
> issue that concur wants to fix), whereas it returns a "normal" value in concur mode.
> 
> In smp mode, the extremly small value returned by task_h_load(p) can be effectively ignored
> in the comparison in wake_affine_weight(). As a result, the condition for returning this_cpu
> becomes:
> 
> cpu_load(cpu_rq(this_cpu)) * 100 < cpu_load(cpu_rq(prev_cpu) * 108
> 
> As a result, this_cpu has a higher chance of being selected in smp mode. In concur mode,
> task_h_load(p) is on par with cpu_load(), so it cannot be simply ignored and provides a fairer
> basis for choosing between this_cpu and prev_cpu. Since netperf/netserver is a sync wakeup, it
> prefers to be co-located on the same CPU/L2 domain for better L2 cache locality.

There is something wonky with task_h_load(), it isn't behaving properly.
I've not managed to put a finger on it yet. Let me continue poking at it.