From: Thomas Gleixner <tglx@linutronix.de>
To: Wladislav Wiebe <wladislav.wiebe@nokia.com>,
anna-maria@linutronix.de, frederic@kernel.org, mingo@kernel.org
Cc: akpm@linux-foundation.org, bigeasy@linutronix.de,
peterz@infradead.org, linux-kernel@vger.kernel.org,
wladislav.wiebe@nokia.com
Subject: Re: [PATCH] irq: add support for warning on long-running IRQ handlers
Date: Mon, 30 Jun 2025 17:42:04 +0200 [thread overview]
Message-ID: <875xgdnsmr.ffs@tglx> (raw)
In-Reply-To: <20250630124721.18232-1-wladislav.wiebe@nokia.com>
On Mon, Jun 30 2025 at 14:46, Wladislav Wiebe wrote:
The subsystem prefix is 'genirq:' See
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#patch-subject
> Introduce a new option CONFIG_IRQ_LATENCY_WARN that enables warnings when
> IRQ handlers take an unusually long time to execute.
>
> When triggered, the warning includes the CPU, IRQ number, handler address,
> name, and execution duration, for example:
>
> [CPU0] latency on IRQ[787:bad_irq_handler+0x1/0x34 [bad_irq]], took: 5 jiffies (~50 ms)
>
> To keep runtime overhead minimal, this implementation uses a jiffies-based
> timing mechanism. While coarse, it is sufficient to detect problematic IRQs.
Define sufficient. That really depends on your use case. For a real-time
system a hard interrupt handler running longer than a few microseconds
can be problematic.
So instead of adding some single purpose mechanism, can we please add
something flexible which can be used for a wide range of scenarios.
> +#ifdef CONFIG_IRQ_LATENCY_WARN
> +static inline void warn_on_irq_latency(struct irqaction *action, unsigned int irq,
> + unsigned long jiffies_start)
latency is the wrong term here. This is about the runtime, duration of
the handler.
> +{
> + unsigned long delta = jiffies - jiffies_start;
> +
> + /*
> + * Warn about long IRQ handler latency only if jiffies are reliable.
What means jiffies are reliable?
> + * The reporting condition hits only when there are at least two CPUs
> + * with active ticks.
> + * Jiffies updates are stalled on this CPU until MAX_STALLED_JIFFIES
> + * reaches and a force update happens on another CPU with active ticks.
> + */
> + if (unlikely(delta >= (MAX_STALLED_JIFFIES + CONFIG_IRQ_LATENCY_WARN_THRESHOLD))) {
> + pr_warn_ratelimited("[CPU%d] latency on IRQ[%u:%pS], took: %lu jiffies (~%u ms)\n",
> + smp_processor_id(), irq, action->handler,
> + delta, jiffies_to_msecs(delta));
> + }
> +}
> +#else
> +static inline void warn_on_irq_latency(struct irqaction *action, unsigned int irq,
> + unsigned long jiffies_start) { }
> +#endif
I'm absolutely not fond of this #ifdeffery and yet more Kconfig
knobs. Something like this should just work:
DEFINE_STATIC_KEY_FALSE(handler_duration_check);
if (static_branch_unlikely(&handler_duration_check))
ts_start = local_clock();
res = action->handler(irq, action->dev_id);
if (static_branch_unlikely(&handler_duration_check))
check_handler_duration(ts_start);
Then have a command-line option which allows the user to set a warning
threshold > 0 in microseconds. When the option is evaluated the
threshold is stored in a __ro_after_init variable and the static branch
is enabled.
Hmm?
Thanks,
tglx
next prev parent reply other threads:[~2025-06-30 15:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-30 12:46 [PATCH] irq: add support for warning on long-running IRQ handlers Wladislav Wiebe
2025-06-30 13:25 ` Peter Zijlstra
2025-06-30 13:59 ` Wladislav Wiebe
2025-07-02 9:06 ` Peter Zijlstra
2025-07-02 9:14 ` Wladislav Wiebe
2025-06-30 15:42 ` Thomas Gleixner [this message]
2025-07-01 6:10 ` Wladislav Wiebe
2025-07-01 7:37 ` Thomas Gleixner
2025-07-15 8:23 ` Wladislav Wiebe
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=875xgdnsmr.ffs@tglx \
--to=tglx@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=anna-maria@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=wladislav.wiebe@nokia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.