Ingo Molnar writes:
> the bug/misbehavior causing bad latencies turned out to be the following:
> if a hardirq triggers a softirq, but syscall-level code on the same CPU
> disabled local bhs via local_bh_disable(), then we 'miss' the execution of
> the softirq, until the next IRQ. (or next direct call to do_softirq()).
Hooray, some sanity in this thread finally :-)
Yes, this makes perfect sense, this is indeed what can happen.
> the attached softirq-2.4.5-B0 patch fixes this problem by calling
> do_softirq() from local_bh_enable() [if the bh count is 0, to avoid
> recursion].
Yikes! I do not like this fix.
I'd rather local_bh_enable() not become a more heavy primitive.
I know, in one respect it makes sense because it parallels how
hardware interrupts work, but not this thing is a function call
instead of a counter bump :-(
Any other ideas how to zap this?
Later,
David S. Miller
davem@redhat.com
-
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/
This archive was generated by hypermail 2b29 : Thu May 31 2001 - 21:00:33 EST