Moving interrupts to threads

So if you have some device which is dominating the machine, like say a network device flooded with tiny packets at line rate, in the old scheme userspace would effectively lock up, and in the new scheme, the network device's handlers will get their fair share of the CPU according to the scheduler.

(This is not a great example because many of the popular network drivers have another mechanism to limit their effect already. But the new scheme is more controlled.)

It also means you can manage the priority of interrupts using thread priorities (RT and non-RT, and "nice"), task control groups, and other things used to manage threads, and they can be dispatched to under-utilised CPUs more efficiently, and interact with thermal and power management.

The need to have quick_check_handler separate from the main handler seems to be due to shared interrupt lines. Without quick_check_handler, multiple devices on the same line would need to share the same handler thread, and interfere with each other.

It's possible to abuse quick_check_handler and write code in the same form as the old top/bottom halves. There are probably some latency-sensitive devices where it's essential to do something more than just acknowledging and disabling the device interrupt. However, that's not the intended way of using it, and if a device is latency sensitive, it should probably use a high RT priority on its handler thread instead. If the thread scheduler is too slow at this, it may be possible to tune this particular path through the scheduler, taking a short cut from irq to task, but retaining the standard scheduling semantics.