Re: [patch V6 10/11] entry: Hook up rseq time slice extension

[Peter Zijlstra <peterz@infradead.org>]

On Sun, Jan 11, 2026 at 12:01:31PM +0100, Thomas Gleixner wrote:

> I know you argued about this many times, but I still maintain my point
> of view that TIF_PREEMPT and TIF_PREEMPT_LAZY are fundmentally different:
> 
>      TIF_PREEMPT_LAZY grants a non-RT task to complete until it reaches
>      return to user
> 
>      TIF_PREEMPT enforces preemption at the next possible preemption
>      point

This is only true for lazy preemption; and that is not the only possible
model.

> My main concern is this scenario:
> 
>    sched_other_task()
>         request_slice_extension()
> 
>    ---> interrupt
>         RT task is woken up
> 
>         return_to_user()
>            grant_extension()
>            ...
> 
> which means the RT task is delayed until the OTHER task relinquishes the
> CPU voluntarily or via timeout.

Which is exactly the same as if there were a kernel preempt_disable()
region.

> So I prefer to keep the current semantics for RT. This can be revisited
> of course when a proper evaluation has been done, but IMO there are too
> many moving parts in a RT system to make this actually work correctly
> under all circumstances.
> 
> I'll add proper comments to that effect.

I've added:

+/*
+ * Since rseq slice ext has a direct correlation to the worst case
+ * scheduling latency (schedule is delayed after all), only have it affect
+ * LAZY reschedules on PREEMPT_RT for now.
+ *
+ * However, since this delay is only applicable to userspace, a value
+ * for rseq_slice_extension_nsec that is strictly less than the worst case
+ * kernel space preempt_disable() region, should mean the scheduling latency
+ * is not affected, even for !LAZY.
+ *
+ * However, since this value depends on the hardware at hand, it cannot be
+ * pre-determined in any sensible way. Hence punt on this problem for now.
+ */