Re: [PATCH v2 2/2] sched/fair: Randomize equally shallow slow-path candidates

[Christian Loehle]

On 9/17/26 17:06, Vincent Guittot wrote:
> On Thu, 17 Sept 2026 at 17:41, Christian Loehle
> <christian.loehle@xxxxxxx> wrote:
>>
>> Picking the first eligible idle CPU leaves a scan-order bias. Concurrent
>> slow-path selectors can choose the same CPU before either task is enqueued.
>>
>> Use reservoir sampling for equal exit latencies, resetting the candidate
>> count when a shallower candidate appears. Use the per-CPU scheduler PRNG
>> and reciprocal_scale() to avoid variable division or a second scan.
>>
>> Use a u64 latency key with U64_MAX for unpublished states. Published
>> states take precedence; when none are found, sample among the idle CPUs
>> without a published state.
>>
>> Signed-off-by: Christian Loehle <christian.loehle@xxxxxxx>
> 
> Reviewed-by: Vincent Guittot <vincent.guittot@xxxxxxxxxx>

Thanks!
FWIW some additional thoughts, in case the unpublished idle state handling
does end up causing regressions (but for now fingers crossed!), there's
of course the option of trying to bucket them into "entering idle" and
"exiting idle" by putting a threshold on rq->idle_stamp.
I've experimented with this, but similarly how it didn't matter if
unpublished states are treated as ideal candidates or worst-idle candidates
this also didn't matter. Throughout various benchmarks about 0.1-0.5% of CPU
candidates are in unpublished state window and with them now counting as
U64_MAX exit_latency they end up being the best candidate of the scan only
extremely rarely (and conversely even rarer is the tie-break between two
unpublished-idle-state CPUs).

> [snip]