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

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Aug 19, 2026 at 09:22:04AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Wed, Aug 19, 2026 at 04:36:49PM +0200, Peter Zijlstra wrote:
> ...
> > > Except that is susceptible to live-locks. It doesn't have forward
> > > progress guarantees. For that we need to limit the amount of
> > > lock-breaks/newidle invocations.
> > 
> > So TJ did something like that for ext. I'm not entirely sure I get his
> > argument on forward progress though.
> 
> For SCX, rq lock is dropped only when a task needs to be migrated to be put
> in the local DSQ and, barring something else happening to it like dequeue or
> competing dispatch, the next time pick_task comes around, the task is going
> to be on the local DSQ, and won't need to drop the lock for that rq and thus
> picking would be able to proceed to the next rq.

Right, but I worry about the cases:

 - there is no ext task pulled to local because $reasons (could be
   cpumask), and we retry, then it will see there are ext tasks, but no
   local and it will try again?

 - custom DSQs, those BPF based things, then we always need to drop the
   lock in order to execute those BPF methods, no?

That is not unlike the case where fair has no local tasks and it will
try and pull some tasks. It will try this every time, and if there are
very few fair tasks in the system, this happens again and again.

As mentioned, one 'hack' I considered was keeping a retry count, and
simply setting 'rf = NULL' after a few cycles, to inhibit any further
balancing and forcing progress.

It just needs making sure all the sched_class::pick_task methods can
deal with !rf, but that shoulnd't be too hard.

> > But the simple thing is something like so, which I think also allows
> > simplifying ext some.
> 
> Oh yeah, if core_seq tracks competing multi-picks, SCX no longer needs to
> track lock drops which was kinda ugly.
> 
> > @@ -6392,7 +6393,7 @@ pick_next_task(struct rq *rq, struct rq_flags *rf)
> >  			if (cookie)
> >  				p = sched_core_find(rq_i, cookie);
> >  			if (!p)
> > -				p = idle_sched_class.pick_task(rq_i, rf);
> > +				p = idle_sched_class.pick_task(rq_i, NULL);
> 
> I guess this is to signify that idle pick shouldn't drop rq lock as it's
> after seq verification?

Indeed. Obviously idle doesn't do balancing, so its trivially correct,
but it is indeed to make clear this is after seq validation.