Yes, interrupts are a signal/symptom and not a cause, they are an indication that the hardware is demanding the cpu’s time. Just like the higher load average is an indication of an issue and not a cause. The cpu’s available time is finite, which makes interrupts finite.
@glb i’m sad that you decided to remove the 100% and instead give Barry a lightbulb 
Maybe a bit off-topic, but can you guys recommend a USB Bluetooth adapter that works great with Linux/Fedora?
Quoting from Is the maximum interrupt frequency for the linux kernel in Hz, kHz, MHz, or GHz? - Stack Overflow
In order to handle an interrupt you need to execute some 100-1000 instructions (save the context, do I/O, signal end of interrupt handling, restore the context). That gives you some
10**6-10**7interrupts per second max.
And USB bus ia simply not fast enough to generate that rate of interrupts.
As I said it’s likely that the kernel’s USB driver is waiting on a timeout and locking up part of the system.
Starting a new topic is likely to get move people to notice your question and answer.
You’re missing my point, it isn’t about the interrupts themselves but about the hardware demanding attention from the cpu. Either by making it take action or by making it wait (through interrupts). When the cpu needs to deal with the misbehaving hardware it will make other processes wait.
These discussions feel very boring and unfruitful to me, so i’m out.
As i mentioned to barry it isn’t about the interrupt rate, it can be a low rate but if the interrupts aren’t answered or closed properly then it will still increase the latency slowly. Over time this will increase the load since other processes have to wait longer than necessary. This is all due to the interrupt handling. The fact that the usb stick is dead doesn’t matter if the OS wouldn’t dedicate time to it, which it only does if it received an interrupt request to interact with the stick.
I do not agree, linux does not work the way you are assuming.
I’ve shared my knowledge on this topic and cannot see it’s worth continuing at the point.
The (pseudo) file /proc/interrupts can show you some statistics bout various interrupts.
Last update on this.
Got a TP-Link UB500 with a RTL8761B chipset and it’s working flawlessly now.
Thank all for you help!
(Marked as solved)
