Re: [PATCHSET sched_ext/for-7.3-fixes] sched_ext: Fix bypass leaving the running task protected and bypassed tasks stranded

[Andrea Righi <arighi@nvidia.com>]

Hi Tejun,

On Fri, Oct 16, 2026 at 07:37:15PM -1000, Tejun Heo wrote:
> Hello,
> 
> scx_bypass() handles the running task inside its walk over the runnable
> list, which never contains the running task, so the protection strip at
> bypass entry never runs. Separately, a bypassing sub-scheduler's tasks are
> run by its nearest ancestor that isn't bypassing, but whether such a task
> may stay on its cpu is still checked against the caps of its own scheduler.
> A bypassed task that the bypass load balancer moved to a cpu where its
> scheduler holds no caps can't stay there once its slice runs out, and the
> cpu can go idle with the task queued on the ancestor's bypass DSQ.
> 
> Patch 1 handles the running task outside the walk. Patch 2 checks a bypassed
> task against the caps of the scheduler running it and, in the block patch 1
> adds, evicts the running task when bypass lifts if its own scheduler lacks
> the caps to keep it.
> 
> Verified on bare metal by attaching and detaching a sub-scheduler repeatedly
> under load. A debug knob that marks the running task protected at each
> bypass entry finds every such task stripped with patch 1. Without it, they
> all keep their protection and the bypass tick can't cut their slices. In a
> VM, running tasks whose scheduler holds no caps on their cpu leave it within
> about 50us of the bypass lift with patch 2, instead of running out their
> bypass slice. The sched_ext selftests pass.

A few notes:

 - when merging for-7.3-fixes into for-7.4, with proxy exec the slice and the
   protection belong to the donor, so I think the resolution should use rq->donor
   instead of rq->curr, both for the strip on bypass and for the eviction on
   unbypass. With rq->curr, a blocked SCX donor would keep its protection into
   bypass and we'd act on the proxy owner instead.

 - not a regression and probably transient (I haven't verified it):
   bypass_lb_cpu() doesn't look at caps, when the nearest non-bypassing ancestor
   running a bypassed sched's tasks is itself a sub-sched with caps only on some
   CPUs, could a bypassed task still be moved to a CPU it can't stay on, until
   bypass lifts?

For the series:

Reviewed-by: Andrea Righi <arighi@nvidia.com>

Thanks,
-Andrea

> 
> Based on sched_ext/for-7.3-fixes (43e1ef14a472).
> 
> This patchset contains the following 2 patches.
> 
>  0001 sched_ext: Fix the running task keeping its protection into bypass
>  0002 sched_ext: Fix a bypassed task stalling on a cpu its scheduler has no caps on
> 
> The patchset is also available in the following git branch:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext.git bypass-stall-fixes
> 
> diffstat follows. Thanks.
> 
>  kernel/sched/ext/ext.c      | 32 +++++++++++++++++++-------------
>  kernel/sched/ext/internal.h | 17 +++++++++++++++++
>  kernel/sched/ext/sub.c      |  7 +++++--
>  kernel/sched/ext/sub.h      |  6 +++++-
>  4 files changed, 46 insertions(+), 16 deletions(-)
> 
> --
> tejun