linux-kernel - Re: Fate of CONFIG_IRQ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3f3d42d2-13e3-43ef-b839-f77424769add@linaro.org>
Date: Mon, 8 Dec 2025 05:49:48 +0100
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Marc Zyngier <maz@...nel.org>, Thomas Gleixner <tglx@...utronix.de>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Fate of CONFIG_IRQ_TIMINGS and co


Hi Marc,

On 12/6/25 11:12, Marc Zyngier wrote:
> Hi both,
> 
> While fixing some ancient MIPS crap, I noticed that the IRQF_TIMER
> flag wasn't being provided to any clockevent driver that uses percpu
> interrupts, starting with the ARM architected timer.
> 
> Thinking that I might as well be fixing that, I started to dig into
> it, only to realise that it is simply impossible to enable the IRQ
> timing subsystem (CONFIG_IRQ_TIMINGS isn't selectable by a luser, and
> TEST_IRQ_TIMINGS depends on it...).
> 
> Even if I manually hack the Kconfig to compile the timing
> infrastructure and allow the selftest to be selected, nothing really
> makes use of this, as the static key that controls the accounting is
> never flipped. The selftest itself only cares about the accounting
> data structure, and not interrupts.
> 
> This appears to be dead code, and seems to have been so for the past 6
> years.
> 
> The obvious question is therefore: why do we have it the first place?

Initially it was to guess estimate when the next interrupt would happen. 
With that information and the next timer expiration, it would have been 
possible to predict the next event on a specific CPU. This information 
was supposed to be used in three context:

  - a cpuidle governor no longer based on the biased statistics for the 
idle durations but on the next event

  - a decision to power down an entire cluster when the last CPU is 
going down because the penalty of having powered down the cluster with a 
CPU waking up immediately is too high

  - a scheduling decision for the deadline scheduler

> It isn't finished, not plugged in, and if it was, would fail to
> correctly account for exactly 100% of the timer interrupts on the
> systems I care about.

  - the next event based governor was implemented at the same time as 
the timer oriented governor and having similar results. It ended up this 
governor was not worth the effort because it would have been duplicate 
in terms of results with the teo governor

  - we had a small bandwidth to work on the cluster power down and for 
the few tests we did, it was not obvious we had an improvement

> If this is a work in progress and that there is a line of sight to
> having it working upstream, that's great, and I will happily post the
> few fixes I have for it. Otherwise, can we do ourselves a favour and
> consider dropping it?

Yes, we already discuss that a few cycles ago with Thomas and, as there 
is no progress, it makes sense to remove it.


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog