Concurrent slow-path selectors can converge on the same idle CPU before
either task is enqueued. Remove the idle-recency preference and randomize
equal-latency choices in a single scan.

The testing platform is a 160-CPU, dual-socket Altra with unusually large
80-CPU candidate groups at NUMA level.

Median stress-ng throughput (bogo ops/s):

  --fork  --fork-max      Baseline       Patched    Change
  ------------------------------------------------------
       1           1        779.19        829.82    +6.50%
      16           1       5070.95       5277.62    +4.08%
      16           4       7692.64       7963.30    +3.52%
      32           1       8662.82       8733.79    +0.82%
      64           1      11880.47      12001.01    +1.01%

Separate instrumented runs observed lower conditional stale-pick rates,
i.e. a busy candidate at final return:

Workload                Baseline       Patched
----------------------------------------------
fork, 32 creators          0.771%       0.335%
fork, 64 creators          1.242%       0.633%

Changes since v1:
- Use u64 latency keys and U64_MAX for unpublished states.
- Sample unpublished-state CPUs only as fallbacks, resetting the reservoir
  when the first advertised-state candidate is found.
- Update the Altra measurements.
- Pick up Vincent Guittot's Reviewed-by for patch 1.

Christian Loehle (2):
  sched/fair: Drop idle recency from slow-path CPU selection
  sched/fair: Randomize equally shallow slow-path candidates

 kernel/sched/fair.c | 31 ++++++++++++-------------------
 1 file changed, 12 insertions(+), 19 deletions(-)


base-commit: fd73f4a6659897191fa0d40695fe370925dd3780
-- 
2.34.1

On 2026.09.17 08:39 Christian Loehle wrote:

> Concurrent slow-path selectors can converge on the same idle CPU before
> either task is enqueued. Remove the idle-recency preference and randomize
> equal-latency choices in a single scan.
>
> The testing platform is a 160-CPU, dual-socket Altra with unusually large
> 80-CPU candidate groups at NUMA level.
>
> Median stress-ng throughput (bogo ops/s):
>
>  --fork  --fork-max      Baseline       Patched    Change
>  ------------------------------------------------------
>       1           1        779.19        829.82    +6.50%
>      16           1       5070.95       5277.62    +4.08%
>      16           4       7692.64       7963.30    +3.52%
>      32           1       8662.82       8733.79    +0.82%
>      64           1      11880.47      12001.01    +1.01%

...

I tried this patch set on my test computer with a Intel
i5-10600K processor. 6 cores, 12 CPUs.
Kernel 7.3-rc3 = baseline
+ this patch set = cl-rand

Conclusion: In general, this patch set was a 1 to 3% improvement.

Note: Test repeatability was a struggle. In the end 2 methods
were used:
1.) flush memory before each test.
2.) to achieve steady state dwell for 15 minutes then use the data afterwards.

Test 1:
9 forks, 60 seconds per test, 25 tests:
Baseline average 65867.05 bogo ops/sec
cl-rand average: 66832.20 bogo ops/sec
change: +1.47%
see also attached graph repeat.png

Test 2: (180 seconds per test)
Forks	baseline	cl-rand		change
1	12071.48	12367.39	2.45%
2	22602.59	23497.74	3.96%
3	32213.33	32462.99	0.78%
4	39746.02	40087.31	0.86%
5	45360.23	47015.42	3.65%
6	54130.07	56579.27	4.52%
7	56944.66	59386.18	4.29%
8	62117.57	63722.8	2.58%
9	62897.63	66471.27	5.68%
10	68009.88	68252.56	0.36%
11	69676.68	71783.96	3.02%
12	75560.96	76041.47	0.64%
13	79663.55	83064.74	4.27%
14	84745.02	85474.34	0.86%
15	85057.97	87075.07	2.37%
16	84897.81	87075.36	2.56%
17	84934.24	86977.66	2.41%
18	84857.44	87068.16	2.61%
19	84300.27	86398.89	2.49%
20	82743.13	86399.7	4.42%
21	84262.03	83751.36	-0.61%
22	83497.87	85038.63	1.85%
23	82650.21	85242.53	3.14%
24	82105.6	84055.71	2.38%
25	82526.08	83319.76	0.96%

Test 3:
9 forks, 3600 second dwell test, data every 20 seconds.
Averages calculated from 17 to 56.67 minutes into test.
The first 17 minutes of data was not used.
Baseline average 59740.52 bogo ops/sec
cl-rand average: 61199.35 bogo ops/sec
change: +2.44%
see also attached graph dwell.png

Test 4:
Concurrent random hdd disk reads from a 500 Gigabyte file.
As the requested jobs per second begins to backup
the patched kernel does better.
See the attached graph actual.png

... Doug