Fate of CONFIG_IRQ_TIMINGS and co

Fate of CONFIG_IRQ_TIMINGS and co

[Marc Zyngier]

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?
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.

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?

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.

Re: Fate of CONFIG_IRQ_TIMINGS and co

[Daniel Lezcano]

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

Re: Fate of CONFIG_IRQ_TIMINGS and co

[Thomas Gleixner]

On Mon, Dec 08 2025 at 05:49, Daniel Lezcano wrote:
>> 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.

Who is going to send the patch?

Re: Fate of CONFIG_IRQ_TIMINGS and co

[Daniel Lezcano]

On 12/10/25 02:13, Thomas Gleixner wrote:
> On Mon, Dec 08 2025 at 05:49, Daniel Lezcano wrote:
>>> 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.
> 
> Who is going to send the patch?


I can send the patches but not before a couple of weeks.


-- 
<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

Re: Fate of CONFIG_IRQ_TIMINGS and co

[Marc Zyngier]

On Wed, 10 Dec 2025 01:13:03 +0000,
Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> On Mon, Dec 08 2025 at 05:49, Daniel Lezcano wrote:
> >> 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.
> 
> Who is going to send the patch?

Series at https://lore.kernel.org/r/20251210082242.360936-1-maz@kernel.org

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.