Messages in this thread | | | From | kuznet@ms2 ... | Subject | Re: [patch] severe softirq handling performance bug, fix, 2.4.5 | Date | Mon, 28 May 2001 23:26:27 +0400 (MSK DST) |
| |
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.
From the other hand note one thing: the problem is old like pyramides. 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. - 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/
| |