Re: [PATCH 13/14] sched: Add {DE,EN}QUEUE_LOCKED

Peter Zijlstra
2025-09-11T09:42:56Z

On Wed, Sep 10, 2025 at 04:01:55PM -1000, Tejun Heo wrote:
> Hello, Peter.
>
> On Wed, Sep 10, 2025 at 05:44:22PM +0200, Peter Zijlstra wrote:
> > Provide a LOCKED queue flag, indicating that the {en,de}queue()
> > operation is in task_rq_lock() context.
> >
> > Note: the sched_change in scx_bypass() is the only one that does not
> > use task_rq_lock(). If that were fixed, we could have sched_change
> > imply LOCKED.
>
> I don't see any harm in doing task_rq_lock() in the scx_bypass() loop.
> Please feel free to switch that for simplicity.

I didn't immediately see how to do that. Doesn't that
list_for_each_entry_safe_reverse() rely on rq->lock to retain integrity?

Moreover, since the goal is to allow:

__schedule()
lock(rq->lock);
next = pick_task() := pick_task_scx()
lock(dsq->lock);
p = some_dsq_task(dsq);
task_unlink_from_dsq(p, dsq);
set_task_cpu(p, cpu_of(rq));
move_task_to_local_dsq(p, ...);
return p;

without dropping rq->lock, by relying on dsq->lock to serialize things,
I don't see how we can retain the runnable list at all.

And at this point, I'm not sure I understand ext well enough to know
what this bypass stuff does at all, let alone suggest means to
re architect this.