Messages in this thread | | | Date | Wed, 17 Jan 2018 22:54:11 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context |
| |
On Wed, 17 Jan 2018, David Miller wrote:
> From: Linus Torvalds <torvalds@linux-foundation.org> > 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.
Errm. No.
> > > 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.
Nope.
raise_softirq() -> raise_softirq_irqoff()
set_softirq_bit();
if (!in_interrupt()) wake_softirqd();
So if the caller is not in hard or soft interrupt context, which includes bottom half disabled regions softirqd is woken.
If the caller is in a bottom half disabled region then local_bh_enable() will run the pending softirqs.
Thanks,
tglx
| |