![]() | ||||||||||
Messages in this thread |
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/ | |||||||||
| Last update: 2005-03-22 13:02 [from the cache] ©2003-2008 | ||||||||||