Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 17 Jan 2018 16:49:32 -0500 (EST)
Message-Id: <20180117.164932.1269304606476934540.davem@davemloft.net>
To:     torvalds@linux-foundation.org
Cc:     efault@gmx.de, peterz@infradead.org, edumazet@google.com,
        dima@arista.com, frederic@kernel.org, linux-kernel@vger.kernel.org,
        0x7f454c46@gmail.com, akpm@linux-foundation.org,
        fweisbec@gmail.com, hannes@stressinduktion.org, mingo@kernel.org,
        alexander.levin@verizon.com, pabeni@redhat.com,
        paulmck@linux.vnet.ibm.com, rrendec@arista.com, riel@redhat.com,
        sgruszka@redhat.com, tglx@linutronix.de, wanpeng.li@hotmail.com
Subject: Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd
 context
From:   David Miller <davem@davemloft.net>
In-Reply-To: <CA+55aFwOv1SBOz6+0GxLxbK5riei83AQRJEHUTXUehSWfBq=Fg@mail.gmail.com>
References: <1515782670.7007.3.camel@gmx.de>
        <20180117.153049.1803664333084879932.davem@davemloft.net>
        <CA+55aFwOv1SBOz6+0GxLxbK5riei83AQRJEHUTXUehSWfBq=Fg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.

> 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.