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

[Tejun Heo]

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.

> 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?

Thanks.

-- 
tejun