Re: sched/fair: which tasks should nr_pref_llc_running be compared against?

[Tim Chen]

On Thu, 2026-08-27 at 21:50 +0800, Zhan Xusheng wrote:
> Reading alb_break_llc() I cannot tell which set of tasks the equality is
> meant to cover:
> 
> 	/* kernel/sched/fair.c:10756 */
> 	if (env->src_rq->nr_pref_llc_running &&
> 	    env->src_rq->nr_pref_llc_running == env->src_rq->cfs.h_nr_runnable) {
> 
> The two counters track different sets.  nr_pref_llc_running is maintained
> from account_entity_enqueue() and account_entity_dequeue() at fair.c:4522
> and 4538, beside cfs_rq->nr_queued++/-- at 4525 and 4541, so it follows
> queued tasks.  h_nr_runnable leaves out delay-dequeued entities:
> set_delayed() decrements it at 6398 while the entity stays queued and
> clear_delayed() restores it at 6418, neither going through
> account_entity_dequeue().
> 
> So with DELAY_DEQUEUE a task that has just gone to sleep holds
> nr_pref_llc_running above h_nr_runnable until it is dequeued for real, the
> equality cannot hold, and alb_break_llc() returns false, which stops
> active load balance from honouring the LLC preference.  The counter is a
> superset of the other, so the error is one-sided: the check can fail to
> protect but never protects wrongly.

Thank you for your review of this code.  You have a valid point that DELAY_DEQUEUE
could cause problem with the check in question. The intention of the check is to take
care of the situation where all running tasks prefer the source LLC, and
we should try not to do active balance that will break LLC locality.
And delayed dequeue of a task preferring source LLC could break the check
unintentionally, even though the rest of running tasks still prefer source LLC.

> 
> Comparing against cfs.h_nr_queued would make both sides agree and read as
> "every queued fair task prefers this LLC".  Keeping runnable semantics
> would instead mean maintaining nr_pref_llc_running from set_delayed() and
> clear_delayed(), which may be the better fit, since only runnable tasks
> are candidates for active load balance and a task on its way to sleep is
> not one.  Which did you have in mind?

I think the proper thing to do is to make sure the nr_pref_llc_running accounts correctly
the number of running tasks that prefer the source LLC.  And
exclude those that are delayed dequeued.  How about the following fix:

Tim

---