public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Thomas Gleixner <tglx@kernel.org>
Cc: arnd@arndb.de, anna-maria@linutronix.de, frederic@kernel.org,
	luto@kernel.org, mingo@redhat.com, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
	vschneid@redhat.com, linux-kernel@vger.kernel.org,
	oliver.sang@intel.com
Subject: Re: [PATCH v2 5/6] entry,hrtimer: Push reprogramming timers into the interrupt return path
Date: Wed, 4 Feb 2026 14:58:13 +0100	[thread overview]
Message-ID: <20260204135813.GL2995752@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <87v7ge4tf6.ffs@tglx>

On Tue, Feb 03, 2026 at 12:28:13AM +0100, Thomas Gleixner wrote:

> But looking at this there is already a problem without interrupt
> nesting:
> 
>         irq_enter_rcu();
>         timer_interrupt()
>           hrtimer_interrupt()
>             delay_rearm();
>         irq_exit_rcu()
>           __irq_exit_rcu()
>             invoke_softirq()  <- Here
> 
> Soft interrupts can run for quite some time, which means this already
> can cause timers being delayed for way too long. I think in
> __irq_exit_rcu() you want to do:
> 
>        if (!in_interrupt() && local_softirq_pending()) {
>          hrtimer_rearm();
>          invoke_softirq();
>        }

Right, and we can do the same on (nested) IRQ entry. Something like so:

---
--- a/kernel/entry/common.c
+++ b/kernel/entry/common.c
@@ -63,6 +63,8 @@ static __always_inline unsigned long __e
 		if (ti_work & (_TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY)) {
 			if (!rseq_grant_slice_extension(ti_work & TIF_SLICE_EXT_DENY))
 				schedule();
+			else
+				hrtimer_rearm();
 		}
 
 		if (ti_work & _TIF_UPROBE)
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -663,6 +663,13 @@ void irq_enter_rcu(void)
 {
 	__irq_enter_raw();
 
+	/*
+	 * If this is a nested IRQ that hits the exit_to_user_mode_loop
+	 * where it has enabled IRQs but before it has hit schedule()
+	 * we could have hrtimers in an undefined state. Fix it up here.
+	 */
+	hrtimer_rearm();
+
 	if (tick_nohz_full_cpu(smp_processor_id()) ||
 	    (is_idle_task(current) && (irq_count() == HARDIRQ_OFFSET)))
 		tick_irq_enter();
@@ -719,8 +726,14 @@ static inline void __irq_exit_rcu(void)
 #endif
 	account_hardirq_exit(current);
 	preempt_count_sub(HARDIRQ_OFFSET);
-	if (!in_interrupt() && local_softirq_pending())
+	if (!in_interrupt() && local_softirq_pending()) {
+		/*
+		 * If we left hrtimers unarmed, make sure to arm them now,
+		 * before enabling interrupts to run SoftIRQ.
+		 */
+		hrtimer_rearm();
 		invoke_softirq();
+	}
 
 	if (IS_ENABLED(CONFIG_IRQ_FORCED_THREADING) && force_irqthreads() &&
 	    local_timers_pending_force_th() && !(in_nmi() | in_hardirq()))
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1279,8 +1279,8 @@ static int __hrtimer_start_range_ns(stru
 
 	if (timer->is_fuzzy) {
 		/*
-		 * XXX fuzzy implies pinned!  not sure how to deal with
-		 * retrigger_next_event() for the !local case.
+		 * Fuzzy requires pinned as the lazy programming only works
+		 * for CPU local timers.
 		 */
 		WARN_ON_ONCE(!(mode & HRTIMER_MODE_PINNED));
 		/*
@@ -1898,7 +1898,7 @@ static __latent_entropy void hrtimer_run
 
 /*
  * Very similar to hrtimer_force_reprogram(), except it deals with
- * in_hrirq and hang_detected.
+ * in_hrtirq and hang_detected.
  */
 static void __hrtimer_rearm(struct hrtimer_cpu_base *cpu_base,
 			    ktime_t now, ktime_t expires_next)

  parent reply	other threads:[~2026-02-04 13:58 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-21 16:20 [PATCH v2 0/6] hrtimer/sched: Improve hrtick Peter Zijlstra
2026-01-21 16:20 ` [PATCH v2 1/6] sched/eevdf: Fix HRTICK duration Peter Zijlstra
2026-01-22 10:53   ` Juri Lelli
2026-02-05  8:38   ` Peter Zijlstra
2026-01-21 16:20 ` [PATCH v2 2/6] hrtimer: Optimize __hrtimer_start_range_ns() Peter Zijlstra
2026-01-22 11:00   ` Juri Lelli
2026-02-02 12:28   ` Thomas Gleixner
2026-01-21 16:20 ` [PATCH v2 3/6] hrtimer,sched: Add fuzzy hrtimer mode for HRTICK Peter Zijlstra
2026-01-22 13:12   ` Juri Lelli
2026-01-23 20:04     ` Steven Rostedt
2026-02-02 14:02   ` Thomas Gleixner
2026-01-21 16:20 ` [PATCH v2 4/6] hrtimer: Re-arrange hrtimer_interrupt() Peter Zijlstra
2026-02-02 14:05   ` Thomas Gleixner
2026-01-21 16:20 ` [PATCH v2 5/6] entry,hrtimer: Push reprogramming timers into the interrupt return path Peter Zijlstra
2026-01-23 20:08   ` Steven Rostedt
2026-01-23 21:04     ` Peter Zijlstra
2026-02-02 14:37   ` Thomas Gleixner
2026-02-02 16:33     ` Peter Zijlstra
2026-02-02 23:28       ` Thomas Gleixner
2026-02-03  8:14         ` Thomas Gleixner
2026-02-04 13:58         ` Peter Zijlstra [this message]
2026-01-21 16:20 ` [PATCH v2 6/6] sched: Default enable HRTICK Peter Zijlstra
2026-01-21 22:24   ` Phil Auld
2026-01-22 11:40     ` Peter Zijlstra
2026-01-22 12:31       ` Phil Auld

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=20260204135813.GL2995752@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=anna-maria@linutronix.de \
    --cc=arnd@arndb.de \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=frederic@kernel.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=oliver.sang@intel.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /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