Messages in this thread | | | From | kuznet@ms2 ... | Subject | Re: route cache DoS testing and softirqs | Date | Thu, 1 Apr 2004 10:43:45 +0400 (MSD) |
| |
Hello!
> I didn't focus much on the irq count, but now that I look at it, it > looks like the biggest source of softirq in irq context is the timer > irq, not the network irq. That explains the problem and why NAPI > couldn't avoid the softirq load in irq context, NAPI avoids the network > irqs, but the softirqs keeps running in irq context. > > So lowering HZ to 100 should mitigate the problem significantly.
Plus local_bh_enable(), which was actually the first source discovered by Robert year ago. It does not contribute now, but Robert could turn it on starting some non-trivial process context workload.
We have lots of places where we do local_bh_disable/enable() several times in row and each of them triggers full do_softirq() run without schedule() in between. See?
The thing which I want to say is: source of do_softirq() does not matter. All of them happening outside of ksoftirqd are equally bad, unaccountable, uncontrollable and will show up in some situation.
What's about some accounting do_softirq() in some way as a starting point? F.e. one way is to account all timer ticks happened while do_softirq() to ksoftirqd instead of current process (I am not sure that this is even possible without race conditions). Or something like that.
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/
| |