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

Hello!

> yep you are right.
> 
> i had this fixed too at a certain point, there is one subtle issue: under
> certain circumstances tasklets re-activate the tasklet softirq(s) from
> within the softirq handler, which leads to infinite loops if we just
> naively restart softirq handling.

Exactly. That's why it is not made in this way. 8)

Actually, Andrea's patch (probably improved) is the only visible
direction to solve this.

It was always present and it is much _lighter_ in 2.4 comparing
f.e. with 2.2, because in 2.4 at least different softirqs are served
with low latency. So, if you guys consider Andrea's solution too cumbersome,
consider at least adding check for pending softirqs in idle task
(f.e. recent patch by Manfred Spraul) and the things still will
be quite satisfactory.

BTW Ingo, probably you missed one different moment in TUX: schedule() points.
If you do not schedule for long time, all the engine stops to work.
F.e. local_bh_disable() made in thread context are legal when and
only when some schedule() or return from syscall will follow really soon.

Alexey

PS Sorry, I am still offline, but returning to life.