Date: Mon, 10 Feb 2003 00:19:08 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Bruce Evans <bde@zeta.org.au> Cc: smp@FreeBSD.ORG Subject: Re: machine/critical.h and !__GNUC__, interrupt nesting level, etc. Message-ID: <20030210081908.GA4772@HAL9000.homeunix.com> In-Reply-To: <20030210045401.I2223-100000@gamplex.bde.org> References: <20030209152414.GA1390@HAL9000.homeunix.com> <20030210045401.I2223-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Bruce Evans <bde@zeta.org.au>: > On Sun, 9 Feb 2003, David Schultz wrote: > > > It seems that each src/sys/$arch/$arch/critical.h contains the > > following: > > > > #else /* !__GNUC__ */ > > > > void cpu_critical_enter(void) > > void cpu_critical_exit(void) > > > > #endif /* __GNUC__ */ > > > > Am I losing my mind or will that cause a compile-time error > > without semicolons at the ends of the lines? There doesn't even > > As you can see, the !__GNUC__ case is rarely tested. > > > seem to be a !__GNUC__ implementation at all, or any irreparable > > gccisms in the normal version for that matter. > > Rev.1.1 of the i386 version was more complicated and had intr_disable() > calls. Even that is not a gccism since intr_disable()'s interface is > not gcc-specific; the function is just implemented using gccism in the > __GNUC__ case, and the details for that are elsewhere. Disabling all > interrupts in these functions is basically a mistake, but may be needed > for unpolished implementations or recalcitrant arches. In the source tree I'm looking at right now (-CURRENT from about three months ago), i386 is the only architecture that doesn't just disable interrupts in critical sections. That's a shame, especially for sparc64 where disabling interrupts is rather expensive. The i386 port also seems to be able to get away with other things for reasons I don't understand; for instance, td_intr_nesting_level is updated without using a lock prefix. I guess that's okay since it's per-CPU state, as long as it's accessed within a critical section. > > Another random question that came up while I was browsing the > > source entirely too late at night: > > > > Why isn't td_intr_nesting_level bounded? Isn't there a danger of > > overflowing the kernel stack? ... > In -current, interrupts are rarely if ever nested, since most interrupt > handling is done in interrupt tasks on separate stacks and switches > to the separate stacks are mostly done with interrupts disabled (perhaps > only in software). I was worried about context stealing, but it looks like that isn't implemented. Thanks for your response. I've picked up a few things to add to the end of my rather long ``ooh, shiny'' list. (You may be relieved to know that context stealing isn't one of them.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030210081908.GA4772>