Re: [patch] softirq-2.4.5-B0
On 27 May 2001, Andi Kleen wrote: > I think the right way to fix it is to do a final atomic check for > softirqs when the kernel is exited. To be atomic this check neededs to > be done with interrupts off until the kernel exited. [...] check out my first softirq patch, it does exactly this. (but has the wrong explanation.) > [...] The same atomic check is needed for race free check of > need_schedule (which is still racy on plain i386). right, this need_resched race is fixed in the lowlatency patchset. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] softirq-2.4.5-B0
"David S. Miller" <[EMAIL PROTECTED]> writes: > > 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? I think the right way to fix it is to do a final atomic check for softirqs when the kernel is exited. To be atomic this check neededs to be done with interrupts off until the kernel exited. I just implemented a very similar way into the x86-64 kernel (which needs to turn off interrupts for kernel anyways for other reasons, this just extends the cli area a bit). The same atomic check is needed for race free check of need_schedule (which is still racy on plain i386). -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] softirq-2.4.5-B0
On Sun, 27 May 2001, David S. Miller wrote: > Hooray, some sanity in this thread finally :-) [ finally i had some sleep after a really long debugging session :-| ] > > 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 think we have no choice, unfortunately. and i think function calls are not that scary anymore, especially not with regparms and similar compiler optimizations. The function is simple, the function just goes in and returns in 90% of the cases, which should be handled nicely by most BTBs. we have other fundamental primitives that are a function call too, eg. dget(), and they are used just as frequently. In 2.4 we were moving inlined code into functions in a number of cases, and it appeared to work out well in most cases. > 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 :-( i believe the important thing is that the function has no serialization or other 'heavy' stuff. BHs had the misdesign of not being restarted after being re-enabled, and it caused performance problems - we should not repeat history. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
