Re: [PATCH 1/2] sched_ext: Fix ops.dequeue() semantics

[Christian Loehle <christian.loehle@arm.com>]

On 1/21/26 12:25, Andrea Righi wrote:
> Currently, ops.dequeue() is only invoked when the sched_ext core knows
> that a task resides in BPF-managed data structures, which causes it to
> miss scheduling property change scenarios. As a result, BPF schedulers
> cannot reliably track task state.
> 
> In addition, some ops.dequeue() callbacks can be skipped (e.g., during
> direct dispatch), so ops.enqueue() calls are not always paired with a
> corresponding ops.dequeue(), potentially breaking accounting logic.
> 
> Fix this by guaranteeing that every ops.enqueue() is matched with a
> corresponding ops.dequeue(), and introduce the SCX_DEQ_ASYNC flag to
> distinguish dequeues triggered by scheduling property changes from those
> occurring in the normal dispatch workflow.
> 
> New semantics:
> 1. ops.enqueue() is called when a task enters the BPF scheduler
> 2. ops.dequeue() is called when the task leaves the BPF scheduler,
>    because it is dispatched to a DSQ (regular workflow)
> 3. ops.dequeue(SCX_DEQ_ASYNC) is called when the task leaves the BPF
>    scheduler, because a task property is changed (sched_change)
> 
> The SCX_DEQ_ASYNC flag allows BPF schedulers to distinguish between a
> regular dispatch workflow and a task property changes (e.g.,
> sched_setaffinity(), sched_setscheduler(), set_user_nice(), NUMA
> balancing, CPU migrations, etc.).
> 
> This allows BPF schedulers to:
> - reliably track task ownership and lifecycle,
> - maintain accurate accounting of enqueue/dequeue pairs,
> - update internal state when tasks change properties.
> [snip]

Cool, so with this patch I should be able to fix my scx_storm BPF
scheduler doing local inserts, as long as I track all the task's status
that are not in a DSQ?
https://github.com/cloehle/scx/commit/25ea91d8f7fea1f31cf426561b432180fb9cf76a
mentioned in
https://github.com/sched-ext/scx/issues/2825

Let me give that a go and report back!