Re: [PATCH v2 3/6] hrtimer,sched: Add fuzzy hrtimer mode for HRTICK

[Juri Lelli <juri.lelli@redhat.com>]

Hello,

On 21/01/26 17:20, Peter Zijlstra wrote:
> Upon schedule() HRTICK will cancel the current timer, pick the next
> task and reprogram the timer. When schedule() consistently triggers
> due to blocking conditions instead of the timer, this leads to endless
> reprogramming without ever firing.
> 
> Mitigate this with a new hrtimer mode: fuzzy (not really happy with
> that name); this mode does two things:

Does the more common (lazier :) 'lazy' work better?

> 
>  - skip reprogramming the hardware on timer remove;
>  - skip reprogramming the hardware when the new timer
>    is after cpu_base->expires_next
> 
> Both things are already possible;
> 
>  - removing a remote timer will leave the hardware programmed and
>    cause a spurious interrupt.
>  - this remote CPU adding a timer can skip the reprogramming
>    when the timer's expiration is after the (spurious) expiration.
> 
> This new timer mode simply causes more of this 'fuzzy' behaviour; it
> causes a few spurious interrupts, but similarly avoids endlessly
> reprogramming the timer.
> 
> This makes the HRTICK match the NO_HRTICK hackbench runs -- the case
> where a task never runs until its slice is complete but always goes
> sleep early.
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---

...

> @@ -1269,6 +1269,19 @@ static int __hrtimer_start_range_ns(stru
>  	if (new_base->cpu_base->in_hrtirq)
>  		return 0;
>  
> +	if (timer->is_fuzzy) {
> +		/*
> +		 * XXX fuzzy implies pinned!  not sure how to deal with
> +		 * retrigger_next_event() for the !local case.
> +		 */
> +		WARN_ON_ONCE(!(mode & HRTIMER_MODE_PINNED));

Not sure either, but since it's improving things for local already,
maybe it's an acceptable first step?

Reviewed-by: Juri Lelli <juri.lelli@redhat.com>

Thanks,
Juri