Softirqs can impose an enormous load on the system when there is a flood of them waiting to be processed. This has been repeatedly seen in the network (and to some extent, block) layers, leading to the development of polled mode IRQ handling; it's called NAPI for the network (receive) path and simply interrupt-poll handling for the block layer. But what if, even with polled mode handling, the softirq flood persists? The kernel has one more trick up its sleeve: if softirq processing exceeds 2 milliseconds, the kernel offloads the pending softirq work onto per-CPU kernel threads named ksoftirqd/n (where n represents the CPU number, starting from 0). A benefit of this approach is that because kernel threads must compete with other threads for CPU resources, user space doesn't end up getting completely starved of CPU (which could happen with pure hardirq/softirq load).
This sounds like a good solution...