Re: [PATCHSET v2 sched_ext/for-7.3] sched_ext: Bandwidth-limited rescue execution for stranded tasks

[Andrea Righi <arighi@nvidia.com>]

Hi Tejun,

On Sun, Aug 02, 2026 at 11:54:35AM -1000, Tejun Heo wrote:
> Hello,
> 
> v2: Changes from the sashiko AI review:
> 
>     - Declare scx_sched_all outside the CONFIG_EXT_SUB_SCHED block, the
>       definition is unconditional (0002).
> 
>     - Track the overload grace and usage-decay timestamps in jiffies_64 so
>       that 32-bit arithmetic on them can't wrap (0009).
> 
>     - Drop the now-unread always_enq_immed rodata mirror (0011).
> 
> v1: https://lore.kernel.org/r/20260801085150.2697653-1-tj@kernel.org
> 
> A sub-scheduler holds only the cids its parent granted and nothing
> guarantees that they cover its tasks' affinities. A task that can run on
> none of them currently has no good ending: the scheduler's insert is
> cap-rejected and reenqueued until the repeat limit ejects the scheduler, or
> the task stalls into the watchdog.
> 
> This series adds kernel-side rescue execution. A scheduler marks an insert
> that may be cap-rejected with SCX_ENQ_RESCUE and the kernel, instead of
> bouncing it, runs the task on the target cpu at a small configured
> bandwidth. A rescue starts out non-disruptive. Schedulers that hold caps on
> the cid largely stay in control of the cpu - a preemption cap, for example,
> still lets its holder preempt the rescuee. When a rescue goes unserved for
> too long, it escalates into protected execution.
> 
> When a cpu's rescue queue stays oversaturated past the overload threshold,
> the kernel ejects the sub-scheduler with the highest recent rescue
> consumption on that cpu instead of misblaming the waiter's owner.

With the updated patch 08/12 everything looks good to me.
For the whole series:

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

Thanks,
-Andrea