Re: [PATCH 0/2] sched: Remove sched_class::balance()

[Peter Zijlstra]

On Fri, Jul 03, 2026 at 09:01:37AM +0530, K Prateek Nayak wrote:
> Hi Aaron,
> 
> On 7/2/2026 5:19 PM, Aaron Lu wrote:
> > Assume cpuX and cpuY are siblings, it appears the following happened:
> > 
> >      cpuX                                      cpuY
> > 
> >    pick_next_task()
> >    goto restart_multi
> > 
> >    rqX->core_pick = pick_task(rqX)
> > 
> >    pick_task(rqY)
> >      pick_task_fair(rqY)
> >        sched_balance_newidle(rqY)
> >          raw_spin_rq_unlock(rqY)  // drops core lock
> > 
> >                                            pick_next_task()
> >                                            goto restart_multi
> >                                            rqY->core_pick = pick_task(rqY)
> >                                            rqX->core_pick = pick_task(rqX)
> > 
> >                                            if (rqX->curr == rqX->core_pick)
> >                                              rqX->core_pick = NULL
> > 
> > 					   UNLOCK rq_lockp(rqY)
> > 
> >          raw_spin_rq_lock(rqY)
> > 
> >    rqY->core_pick = pick_task(rqY)
> > 
> >    p = rqX->core_pick        // NULL
> >    cookie_equals(p, cookie)  // NULL deref
> 
> I also feel doing a balance before the core_cookie is finalized can
> move tasks wrongly to a particular core, only to make them wait later
> because the pick converted on a different core cookie. Stealing via
> balance callback still seems like a good option.
> 
> Then there is the whole issue of core_pick_seq possibly being updated
> by another CPU on the core by the time rq_lock is dropped and grabbed
> again. Afaict, anything that drops the core-wide lock should just do
> a RETRY_TASK if a new task arrives so everything is re-done withing
> a single core-wide lock critical-section.
> 
> Up until this cleanup, only fair and ext used the RETRY_TASK
> mechanism and fair bypassed the newidle with core-sched enabled so
> it never used the RETRY_TASK mechanism with core-sched so I'm still
> skeptical on balance for core-sched being done as part of pick.
> 
> Maybe Peter will have a way to sort it out after he is back from
> vacation if he hasn't got it all figured out already ;-)

Only bad ideas so far. The whole sched_ext thing [1] makes it more
complicated than I'd like.

[1] https://lore.kernel.org/r/20260819093751.GI1247881@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx