Re: [PATCH v4 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 15:38:22 +0200 Valentin Schneider <vschneid@xxxxxxxxxx> wrote:

> > +			/*
> > +			 * @busiest dropped its rq_lock in the middle of
> > +			 * scheduling out its ->curr task (->on_rq := 0), no
> > +			 * need to forcefully punt it away with active balance.
> > +			 */
> > +			if ((busiest->curr->sched_class == &fair_sched_class) &&
> > +			    !busiest->curr->on_rq)
> > +				goto no_active_balance;
> 
> I hadn't thought about that 'busiest->curr == CFS' condition much until
> now; I thought we had something already to prevent active load balance from
> accidentally poking at RT/DL tasks, but I must have been thinking about [1]
> which never went anywhere
> 
> Either way, we could probably get rid of it and have that be just a
> '!busiest->curr->on_rq' check.
> 
> [1]: https://lore.kernel.org/lkml/20190815145107.5318-5-valentin.schneider@xxxxxxx/

I looked at several discussions in the link you provided, and if
busiest->curr is not a CFS task, then directly detaching and attaching
from the CFS tasks without using the stop work is indeed an
optimization. But as Vincent point out, it does add another code path
for detach/attach.

I think I should follow your suggestion and remove the check for
busiest->curr->sched_class. First, removing the check for
busiest->curr->sched_class will not decrease the number of successful
active_balance cases much. Secondly, in the layout of task_struct, the
position of sched_class is quite distant from on_cpu, which may belong
to different cache lines, while on_rq and on_cpu are closer together and
might belong to the same or adjacent cache lines. The previous traversal
of cfs_tasks will check on_cpu in can_migrate_task(), so the additional
check for on_rq will not incur much cpu cycle loss, whereas the
sched_class check is more likely to introduce cache pollution on the src
cpu.

Thanks
Xin Zhao