From: Thomas Gleixner <tglx@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>,
Joe Talbott <joetalbott@gmail.com>
Cc: kernel test robot <oliver.sang@intel.com>,
oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [tip:sched/hrtick] [hrtimer] 2889243848: stress-ng.timermix.ops_per_sec 30.1% regression
Date: Wed, 11 Mar 2026 10:40:20 +0100 [thread overview]
Message-ID: <87cy1ar9ff.ffs@tglx> (raw)
In-Reply-To: <20260310190221.GE652779@noisy.programming.kicks-ass.net>
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/202603102229.74b9dee4-lkp@intel.com/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
next prev parent reply other threads:[~2026-03-11 9:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 14:46 [tip:sched/hrtick] [hrtimer] 2889243848: stress-ng.timermix.ops_per_sec 30.1% regression kernel test robot
2026-03-10 15:23 ` Peter Zijlstra
2026-03-10 17:11 ` Joe Talbott
2026-03-10 18:16 ` Peter Zijlstra
2026-03-10 18:50 ` Peter Zijlstra
2026-03-10 19:02 ` Peter Zijlstra
2026-03-11 9:40 ` Thomas Gleixner [this message]
2026-03-11 10:58 ` Peter Zijlstra
2026-03-11 12:15 ` Peter Zijlstra
2026-03-11 20:16 ` [tip: sched/hrtick] hrtimer: Less agressive interrupt 'hang' handling tip-bot2 for Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cy1ar9ff.ffs@tglx \
--to=tglx@kernel.org \
--cc=joetalbott@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=peterz@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox