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

On Wed, Mar 11, 2026 at 10:40:20AM +0100, Thomas Gleixner wrote:
> 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.

Oh indeed. And that avoids __hrtimer_reprogram() from coming in and
'destroying' the delay I suppose.

Let me poke at this a little more then.