Re: [PATCH 1/2] sched_ext: Add lazy preemption support

[Andrea Righi <arighi@nvidia.com>]

Hi Tao,

On Fri, Sep 18, 2026 at 11:35:25AM +0800, Tao Cui wrote:
> Hi Andrea,
> 
> 在 2026/9/17 15:02, Andrea Righi 写道:
> > The fair scheduling class can request lazy rescheduling, deferring an
> > in-kernel scheduling boundary until returning to user space or until the
> > next scheduler tick. sched_ext only exposes immediate preemption,
> > preventing BPF schedulers from making the same trade-off.
> > 
> > Add SCX_ENQ_PREEMPT_LAZY and SCX_KICK_PREEMPT_LAZY. Both expire the
> > current sched_ext task slice but request lazy rescheduling. Immediate
> > preemption, WAIT and plain kicks take precedence when requests are
> > combined, while a lazy enqueue to a non-local DSQ retains the
> > head-insertion semantics of SCX_ENQ_PREEMPT.
> > 
> > Add SCX_OPS_LAZY_SLICE_EXPIRY as the default expiry policy for newly
> > enabled tasks and initialize it before ops.enable(). Add
> > scx_bpf_task_set_slice_expiry() so the owning scheduler can override the
> > policy per task from any callback while preserving sub-scheduler task
> > ownership boundaries. Bypass continues to force immediate expiry.
> > 
> > For an infinite-slice task whose tick is stopped, set the lazy
> > reschedule request before restoring the scheduler tick dependency. This
> > lets the dependency update's IPI serve the request on return to user
> > space and guarantees that the next tick promotes it otherwise. Use
> > pinned rq locking for remote kick delivery so RQCF_UPDATED reflects
> > clock updates since lock acquisition.
> > 
> > Accumulate kick requests independently and resolve precedence while
> > holding the target rq lock. Reject invalid SCX_KICK_IDLE combinations
> > and unknown kick flags, which were previously silently ignored.
> > 
> 
> I tested v6 on sched_ext/for-7.4 in a 4-CPU KVM guest: wakeup latency
> of a 1ms-period timer task under a scx_simple-based probe scheduler
> (SCX_OPS_LAZY_SLICE_EXPIRY) with a busy loop on the same CPU.
> 
>                      avg     p50     p99
>   CFS (no scx)        60      59      66
>   no wake preempt  20919   20982   21002
>   SCX_ENQ_PREEMPT     59      58      64
>   SCX_ENQ_PREEMPT_LAZY 59     59      64
>   CFS (control)       60      59      68
> 
> (usecs, 2000 iterations each)
> 
> Lazy and immediate preemption are identical here and on par with CFS,
> i.e. no wakeup latency regression in the common case, matching the
> intended semantics. SCX_OPS_LAZY_SLICE_EXPIRY also cut the context
> switch rate of 6 busy hogs from ~1000/s (CFS) to ~215/s. Repeated
> cgroup knob churn (cpu.weight/cpu.idle) ran clean, no warnings in
> dmesg.
> 
> Overall the series looks well-behaved in these scenarios. Thanks for
> working on this!
> 
> Tested-by: Tao Cui <cuitao@kylinos.cn>

Thanks for testing and sharing the results!

-Andrea