Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [RFC PATCH] arm64: defconfig: Disable fine-grained task level IRQ time accounting | Date | Thu, 06 Aug 2020 20:58:26 +0200 |
| |
Peter,
peterz@infradead.org writes: > On Thu, Aug 06, 2020 at 11:41:06AM +0200, Thomas Gleixner wrote: >> And that has nothing to do >> with a silly test case. Sporadic runaways due to a bug in a once per >> week code path simply can happen and having the safety net working >> depending on a config option selected or not is just wrong. > > The safety thing is concerned with RT tasks. It doesn't pretend to help > with runnaway IRQs, never has, never will.
Of course not. But without irq accounting the runtime is accounted on the runaway task which causes it to throttle.
> The further extreme is an interrupt storm, those have always taken a > machine down.
If every interrupt is actually handled, then yes.
> Accounting unrelated IRQ time to RT tasks is equally wrong, the task > execution is unrelated to the IRQs. The config option at least offers > insight into where time goes -- and it's a config option because doing > time accounting on interrupts adds overhead :/
Right, but it's not totally out of the world either to make the throttler do:
if (rt_runtime + irq_time > threshold) try_to_keep_the_box_alive()
> This really is a no-win all round.
That's not the question here :)
> The only 'sensible' option here is threaded IRQs, where the IRQ line > gets disabled until the handler thread has ran, that also helps with IRQ > storms.
I'm not against enforcing threaded IRQs. :)
Thanks,
tglx
| |