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

[Christian Loehle <christian.loehle@arm.com>]

On 10/1/26 14:43, Peter Zijlstra wrote:
> 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.

Alright, I guess the same reasoning then for 5/5?
Again these are all just from throwing a bunch of artificial rt-app tests
against Vincent's patchset and seeing what sticks...