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

From: Peter Zijlstra

Date: Tue Mar 10 2026 - 15:02:37 EST


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/202603102229.74b9dee4-lkp@xxxxxxxxx/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;
}
hrtimer_rearm_event(expires_next, deferred);