From: Linus Torvalds <[email protected]> Date: Wed, 17 Jan 2018 13:06:58 -0800
> It was in some way always a "poor mans interrupt thread" (with no > blocking like a real thread context, but at least not impacting actual > interrupt latency). Or in this loopback device case (and tunnel decapsulation) a poor man's longjmp, releasing the current stack frame to keep the depth in check. Anyways... > That said, this made me wonder a bit. I wonder how bounded the latency > is for raising a softirq from process context. We only _check_ the > softirq on the last hardirq exit, I think. System call return checks it, otherwise this situation would be completely bolixed. > I wonder if we should run softirqs on return to user mode (and make > softirq set a thread flag if not in interrupt context). I'm pretty sure we already do.
