Re: [tip:sched/hrtick] [hrtimer] 2889243848: stress-ng.timermix.ops_per_sec 30.1% regression

On Tue, Mar 10 2026 at 20:02, Peter Zijlstra wrote:

> On Tue, Mar 10, 2026 at 07:50:06PM +0100, Peter Zijlstra wrote:
>> On Tue, Mar 10, 2026 at 07:16:51PM +0100, Peter Zijlstra wrote:
>> > On Tue, Mar 10, 2026 at 01:11:09PM -0400, Joe Talbott wrote:
>> > 
>> > > It looks like it can be found here:
>> > > https://download.01.org/0day-ci/archive/20260310/[email protected]/repro-script
>> > > 
>> > > stress-ng --timeout 60 --times --verify --metrics --no-rand-seed --timermix 64
>> > 
>> > Thanks, that does indeed work and show the regression.
>> > 
>> > Lets see if I can spot the fail...
>> 
>> It looks like that benchmark manages to trip significant nr_hangs, and
>> yes, I made those more expensive because those were not expected to
>> actually happen at any sane rate.
>> 
>> Lets see if we can cure that without making a giant mess of things.
>
> Ha! This seems to work just fine.
>
> ---
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index b94bd56b739f..9872dd53f761 100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -2031,7 +2031,8 @@ static void hrtimer_rearm(struct hrtimer_cpu_base *cpu_base, ktime_t expires_nex
>  		 * Give the system a chance to do something else than looping
>  		 * on hrtimer interrupts.
>  		 */
> -		expires_next = ktime_add_ns(ktime_get(), 100 * NSEC_PER_MSEC);
> +		expires_next = ktime_add_ns(ktime_get(),
> +					    min(100 * NSEC_PER_MSEC, cpu_base->max_hang_time));
>  		cpu_base->hang_detected = false;

Hmm. The original code preserved hang_detected until the next timer
interrupt to prevent rearming when a new timer is queued.

Thanks,

        tglx