On Tue, Jan 9, 2018 at 9:48 AM, Linus Torvalds
[off-list ref] wrote:
On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet [off-list ref] wrote:
quoted
So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has
shown up multiple times in various 'regressions'
simply because it could surface the problem more often.
But even if you revert it, you can still make the faulty
driver/subsystem misbehave by adding more stress to the cpu handling
the IRQ.
..but that's always true. People sometimes live on the edge - often by
design (ie hardware has been designed/selected to be the crappiest
possible that still work).
That doesn't change anything. A patch that takes "bad things can
happen" to "bad things DO happen" is a bad patch.
I was expecting that people could get a chance to fix the root cause,
instead of trying to keep status quo.
Strangely, it took 18 months for someone to complain enough and
'bisect to this commit'
Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate
handling', but TCP Small queues heavily use TASKLET,
so as far as I am concerned a revert would have the same effect.