Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

[Linus Torvalds]

On Thu, Jan 11, 2018 at 11:48 AM, Eric Dumazet <edumazet@xxxxxxxxxx> wrote:
> That was the purpose on the last patch : As soon as ksoftirqd is scheduled
> (by some kind of jitter in the 99,000 pps workload, or antagonist wakeup),
> we then switch to a mode where process scheduler can make decisions
> based on threads prios and cpu usage.

Yeah, but that really screws up everybody else.

It really is a soft *interrupt*. That was what it was designed for.
The thread handling is not primary, it's literally a fallback to avoid
complete starvation.

The fact that networking has now - for several years - tried to make
it some kind of thread and get fairness with user threads is all
entirely antithetical to what softirq was designed for.

> Then, as soon as the load was able to finish in its quantum the
> pending irqs, we re-enter the mode
> where softirq are immediately serviced.

Except that's not at all how the code works.

As I pointed out, the softirq thread can be scheduled away, but the
"softiq_running()" wil stilll return true - and the networking code
has now screwed up all the *other* softirqs too!

I really suspect that what networking wants is more like the
workqueues. Or at least more isolation between different softirq
users, but that's fairly fundamentally hard, given how softirqs are
designed.

My dvb-fixing patch was an *extremely* stupid version of that "more
isolation".  But it really is a complete hack, saying that tasklets
are special and shouldn't trigger ksoftirqd. They're not really all
that special, but it at least isolated the USB/DVB usage from the
"networking wants softirqd" problem.

                    Linus