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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aXIiPDGZdqmFOvBJ@jlelli-thinkpadt14gen4.remote.csb>
Date: Thu, 22 Jan 2026 14:12:28 +0100
From: Juri Lelli <juri.lelli@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: tglx@...utronix.de, arnd@...db.de, anna-maria@...utronix.de,
	frederic@...nel.org, luto@...nel.org, mingo@...hat.com,
	vincent.guittot@...aro.org, dietmar.eggemann@....com,
	rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
	vschneid@...hat.com, linux-kernel@...r.kernel.org,
	oliver.sang@...el.com
Subject: Re: [PATCH v2 3/6] hrtimer,sched: Add fuzzy hrtimer mode for HRTICK

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@...radead.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@...hat.com>

Thanks,
Juri