Re: [PATCH v2 1/5] sched/fair: Take slice protection into account when arming HRTICK

[Peter Zijlstra]

On Thu, Oct 01, 2026 at 02:40:12PM +0100, Christian Loehle wrote:
> EEVDF can end a task's slice protection before its virtual deadline when
> shorter requests compete on the runqueue. update_curr() requests a new
> selection once protection expires, but hrtick_start_fair() still arms the
> timer for the virtual deadline. Without an intervening scheduling event,
> the next opportunity to reconsider the task can therefore arrive much
> later than the protection boundary.
> 
> Arm the fair hrtick for the earlier of the virtual deadline and live
> slice protection. Keep the deadline fallback once protection expires.
> With RUN_TO_PARITY disabled, vprot remains the minimum progress quantum,
> so the timer must reconsider current at that boundary too. A same-task
> repick restarts the timer without renewing protection, so newly eligible
> tasks can compete without waiting for another protected quantum.
> 
> A wakeup can shorten protection without preempting current. The enqueue
> path calls hrtick_update() before wakeup_preempt_fair() updates protection,
> and hrtick_update() leaves an active timer alone. Recompute the fair
> hrtick after update_protect_slice() changes vprot, including when a timer
> is already active. If the new protection boundary has already passed,
> request lazy rescheduling, as update_curr() does on protection expiry,
> instead of falling back to the later deadline.
> 

Right, so I don't much like this. This wrecks the steady state behaviour
in favour of our 'dodgy' wakeup heuristics.

I would much rather we stick to the paper for steady state, and let
wakeups be wakeups.