> what are you trying to argue, that it's incorrect to re-process softirqs
> if they got activated during the previous pass? I told a number of
> fundamental reasons
I did not find them in your mails.
> (Lets assume that a loop of 10 still ensures basic safety in situations
> where external load overloads the system.
It does not, evidently. And 1 does not. But 10 is 10 times worse.
> Is your point to make the softirq loop to be sysctl-tunable?
No. My point is to make it correctly eventually.
If you will repeat such attempts to "improve" it each third 2.4.x,
it will remain broken forever.
> show you slow enough systems which can be overloaded via hardirqs alone.)
This problem has been solved ages ago. The only remaining question
is how to make this more nicely.
> I think the technically most reasonable approach is to process softirqs
> *as soon as possible*,
...
> please point out flaws in this thinking.
They are processed as soon as possible.
Ingo, I told net_rx_action() is small do_softirq() restarting not 10,
but not less than 300 times in row.
If this logic is wrong, you should explain why it is wrong.
Looping dozen of times may look like cure, but for me it still
looks rather like steroids.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/