Re: [RFC PATCH RESEND 03/10] sched/fair: Clear active_balance at the end of active_load_balance_cpu_stop()

[Xin Zhao]

On Thu, 10 Sep 2026 13:39:10 +0530 K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:

> > The rq->active_balance flag is used to prevent multiple CPUs from
> > simultaneously dispatching active balance stop tasks. Since there can only
> > ever be one consumer of the stop task, it is not strictly necessary to
> > protect the setting of rq->active_balance to 0 with the rq lock in
> > active_load_balance_cpu_stop(). Therefore, we can move the action of
> > clearing rq->active_balance to the end of active_load_balance_cpu_stop().
> > The benefit of this approach is that the task load of dst_rq will change
> > due to the execution of attach_one_task(), which helps avoid prematurely
> > clearing rq->active_balance before attach_one_task(), thus preventing
> > unnecessary dispatch of duplicate active balance stop tasks.
> 
> Aren't we moving tasks *out* of the busiest CPU where the stopper is
> scheduled?
> 
> As soon as we do detach_one_task() within the rq_lock, the load is
> reflected correctly. There is no need to wait until we attach task to
> a remote target_rq. TASK_ON_RQ_MIGRATING will immediately detach its
> PELT signal from busiest.
> 
> That last statement seems to be inaccurate.

The load on the source CPU is indeed updated after detach_one_task, but the
load on the destination CPU is not.

Suppose that while sched_balance_rq() is being executed on CPU A, an active
balance triggered with the source being CPU B and the destination being CPU A.

Meanwhile, CPU C might also be executing sched_balance_rq() and changing the
destination CPU to CPU A (referring to the code related to

env.dst_rq =_rq(env.new_dst_cpu);). 

If the active_balance flag is cleared to 0 before attach_one_task(), then CPU C
may trigger a duplicate active balance from source CPU B to destination CPU A.
If I'm not mistaken, I may need to add this explanation to the commit log.


> As soon as we enable IRQs, a timer for a remote tick may go off which
> may want to push the task from this CPU again but it sees
> ->active_balance still set.
> 
> At the very least, I think this should be done before IRQs are enabled
> but I'm not convinced by the justification for this in the commit
> message.
> 
> > +	busiest_rq->active_balance = 0;
> >  
> >  	return 0;
> >  }

I understand. Indeed, the action of clearing the active_balance flag after
enabling interrupts is completely unnecessary; it should be placed before
enabling interrupts.

--
Xin Zhao