Re: [PATCH v3 1/2] sched/fair: Don't trigger active lb if src_rq->curr is CFS and not on_rq

[Xin Zhao]

On Tue, 16 Jun 2026 11:06:54 +0800 "Aiqun(Maria) Yu" <aiqun.yu@xxxxxxxxxxxxxxxx> wrote:

> >> +			 * need to forcefully punt it away with active balance.
> >> +			 */
> >> +			if ((busiest->curr->sched_class == &fair_sched_class) &&
> >> +			    !busiest->curr->on_rq)
> 
> Still have the doubt why need to do active load balance when the current
> is not CFS. And busiest->curr->on_rq==0 case only.
> 
> Is it should be like:
> if ((busiest->curr->sched_class == &fair_sched_class) ||
> unlikely(!task_on_rq_queued(busiest->curr)));

The platform I am using is quite close to actual usage, and the tasks
bound to different CPUs and different scheduling domains vary
significantly. From my data, there isn't a single CPU with an active
balance success rate below 50% under such scenarios. As for your earlier
comment that "just do detach_task and attach_task and the success rate
will be 100%", I believe you should take a closer look at the
implementation of active_load_balance_cpu_stop. That should make it clear
where the statistical code I previously sent you is located, instead of
simply questioning my approach of performing an ineffective "detach_task
and attach_task" operation to artificially inflate the success rate during
testing.

Regarding why the success rate of active balance is so high in this case,
I have my own reasonable explanations, and I prefer not to repeat them
over and over.

> if busiest->curr->on_rq==2 (TASK_ON_RQ_MIGRATING), it is no need to do
> active_balance as well.

There is a slight difference for the compiler between comparing == 1 and
comparing != 0. From my current understanding, comparing to a non-zero
value is generally faster than comparing to a specific number in most of
arch. I have previously tested whether on_rq would ever be equal to 2 and,
over a long period of time, I did not encounter a single instance where
on_rq was 2. This at least indicates that the probability is extremely
low, and it may even be theoretically impossible for such a situation to
occur.

Thanks
Xin Zhao