Messages in this thread | | | From | "David S. Miller" <> | Date | Sat, 26 May 2001 16:55:06 -0700 (PDT) | Subject | Re: [patch] severe softirq handling performance bug, fix, 2.4.5 |
| |
Ingo Molnar writes: > (unlike bottom halves, soft-IRQs do not preempt kernel code.) ...
Since when do we have this rule? :-)
> the two error cases are: > > #1 hard-IRQ interrupts user-space code, activates softirq, and returns to > user-space code > > #2 hard-IRQ interrupts the idle task, activates softirq and returns to > the idle task. > > category #1 is easy to fix, in entry.S we have to check active softirqs > not only the exception and ret-from-syscall cases, but also in the > IRQ-ret-to-userspace case. > > category #2 is subtle, because the idle process is kernel code, so > returning to it we do not execute active softirqs. The main two types of > idle handlers both had a window do 'miss' softirq execution:
Ingo, I don't think this is the fix.
You should check Softirqs on return from every single IRQ. In do_softirq() it will make sure that we won't run softirqs while already doing so or being already nested in a hard-IRQ.
Every port works this way, I don't know where you got this "soft-IRQs cannot run when returning to kernel code" rule, it simply doesn't exist.
And looking at the x86 code, I don't even understand how your fixes can make a difference, what about the do_softirq() call in arch/i386/kernel/irq.c:do_IRQ()??? That should be taking care of all these "error cases" right?
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/
| |