Messages in this thread | | | From | "David S. Miller" <> | Date | Sun, 27 May 2001 12:15:10 -0700 (PDT) | Subject | Re: [patch] softirq-2.4.5-B0 |
| |
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/
| |