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

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Aug 19, 2026 at 09:42:14PM -1000, Tejun Heo wrote:
> Hello, Peter.
> 
> On Thu, Aug 20, 2026 at 09:18:52AM +0200, Peter Zijlstra wrote:
> ...
> > 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?
> 
> For SCX, rq lock is not dropped for "trying". It is only dropped when there
> is a task to be migrated, so if nothing has changed since the last time,
> there won't be a task to migrate and thus no lock drop.

Hmm, right. I don't think I can get fair to behave that way in a hurry.
Also, even if I could, the figuring out if there is anything to move
might still be somewhat expensive to retry multiple times.

Let me continue pondering if there is anything saner than simply
clearing rf.

> >  - custom DSQs, those BPF based things, then we always need to drop the
> >    lock in order to execute those BPF methods, no?
> 
> No, those all nest inside rq locks. Think about enqueue path. Enqueue needs
> to run all those and we don't drop rq lock while enqueueing (unless we're
> bouncing to another rq's local DSQ at least).

Oh right.. bah, I keep forgetting how all that works :/