Re: Softirq priority inversion from "softirq: reduce latencies"

On 02/29/2016 07:40 AM, Mike Galbraith wrote:

On Mon, 2016-02-29 at 07:03 -0800, Peter Hurley wrote:

quoted

quoted

If I'm listening properly, the root cause is that there is a timing
constraint involved, which is being exposed because one softirq raises
another (ew).

Not the case. The softirq is raised from interrupt.

Yeah, saw that on re-read.

quoted

Before Eric's change, when an interrupt raises a new softirq
while processing another softirq, the new softirq is immediately
processed *after the existing softirq completes*.

Not necessarily, Eric only changed it from an arbitrary count to an
arbitrary time, so your irq could just as well land when there's no
count left and be up the same creek.

Your misreading the softirq abort logic:
neither 2ms nor a fixed number of loops has elapsed.

All that's happened is the first loop of NET_RX softirq has woken a
process; that is sufficient to abort softirq and defer it for ksoftirqd.

That's why I'm saying this is a priority inversion, and one that
will happen a lot.

I was more infatuated by the constraint that's left dangling in the
breeze any time processing is deferred to ksoftirqd.

	-Mike