Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Andi Kleen <andi@firstfloor.org>]

> while I don't disagree that oprofile will give you more detailed
> results, I think there's a HUGE difference between asking a bugreporter
> "can you paste a screen of 'top'" and "can you configure and run
> oprofile".

Perhaps the better fix would be to make oprofile easier to configure.
I never quite understood for example why it doesn't get the symbol
table simply from the kallsyms. Or simply unpacks gzip'ed vmlinux
by itself.

> CHances are good that the user already thought of top him/herself and
> just reports "interrupt X is eating CPU" rather than "something seems
> to be eating CPU".

> 
> I'm not going argue that this alone is enough justification for
> irqthreads, but you can't deny it's an advantage.

Do we have that many cases of runaway irqs? The only common
one I can think of is ACPI, but that is a separate thread already.

Or for networking high performance goes into polling mode
and most of the work is outside hardirq so it wouldn't be visible
in the thread statistics either. But even there livelocks are not
very common.

Also that would assume that the proposed opt in irq threads are used
for all interrupts.

-Andi