Re: [patch] severe softirq handling performance bug, fix, 2.4.5

[David S. Miller]

Andrea Arcangeli writes:
 > 	if (softirq_active(cpu) & softirq_mask(cpu)) {
 > 	    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 > 
 > I mean everything is fine until the same softirq is marked active again
 > under do_softirq, in such case neither the do_softirq in do_IRQ will
 > run it (because we are in the critical section and we hold the per-cpu
 > locks), nor we will run it again ourself from the underlying do_softirq
 > to avoid live locking into do_softirq.

"live lock".  What do you hope to avoid by pushing softirq processing
into a scheduled task?  I think doing that is a stupid idea.

You are saying that if we are getting a lot of soft irqs we should
defer it so that we can leave the trap handler, to avoid "live lock".

I think this is a bogus scheme for several reasons.  First of all,
deferring the processing will only increase the likelyhood that the
locality of the data will be lost, making the system work harder.

Secondly, if we are getting softirqs at such a rate, we have other
problems.  We are likely getting surged with hardware interrupts, and
until we have Jamals stuff in to move ethernet hardware interrupt
handling into softirqs your deferrals will be fruitless when they do
actually trigger.  We will be livelocked in hardware interrupt
processing instead of being livelocked in softirq processing, what an
incredible improvement. :-)

Therefore I recommend that the softirqs are implemented on x86 how at
least I intended the damn things to be implemented, on every return
from trap, no matter what kind, call do_softirq if softirqs are
pending.

Again, I am totally against ksoftirqd, I think it's a completely dumb
idea.  Softirqs were meant to be as light weight as possible, don't
crap on them like this with this heavyweight live lock "solution".
It isn't even solving live locks, it's rather trading one kind for
another with zero improvement.

Later,
David S. Miller
[e-mail]