Sorry it took me so long to test and to reply back, I'm very busy, I
anounced this a couple of days ago on #kernelnewbies and I've been willing
to reply back to you, well, here it is...
> This is why it's confusing; run the same tests for both 2.2 and 2.4
> Also the 2.4 kernels before ksoftirq was introduced; try 2.4.5 vs 2.4.10
> (although iam sure those results will be inconclusive since there may be
> other issues such as VM etc that might be affecting you).
This was a very good clue, I had tested 2.4s from .6 and up but not .5 when
I tested it the results were the same as on 2.2 series, as a result, softirq
related code was blamed.
Then Rik van Riel passed me a patch to the ksoftirq code to let do_softirq
loop, I applied that to 2.4.10 and things got much better, so definitely the
problem was related to the softirq handling.
Some days ago I tested 2.4.13pre6 and I found out that the problem with
softirq was gone, the performance was the same as on 2.2 series, even better
I'd say, I could ssh to my smp machine, a dual P133, during a udpspam storm
from the PIII 868 and do things through ssh, it was slow of course, but
worked, that is unthinckable even on 2.2 kernels on that machine.
Then I downgraded till I reached 2.2.11 finding that this and newer kernels
were ok regarding to this problem (Inicial tests had been done on kernels
from 2.4.6 to 2.4.10, exactly the ones that presented this problem).
So to sumarice things up: The problem was on kernels 2.4.6 to 2.4.10, I
think it was caused by softirq related code. The problem got solved on
Manty/BestiaTester -> http://manty.net