Date: Tue, 11 Feb 2003 00:37:28 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: David Schultz <dschultz@uclink.Berkeley.EDU> Cc: smp@FreeBSD.ORG Subject: Re: machine/critical.h and !__GNUC__, interrupt nesting level, etc. Message-ID: <20030211002023.C1011-100000@gamplex.bde.org> In-Reply-To: <20030210081908.GA4772@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 Feb 2003, David Schultz wrote: > Thus spake Bruce Evans <bde@zeta.org.au>: > > On Sun, 9 Feb 2003, David Schultz wrote: > > > [cpu_crtical_enter...] > > 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. AFAIK (not far) sparc64 has 2 layers of hardware interrupt disabling which gives it some similar benefits to the i386 hardware/software interrupts (disabling interrupts at a high level doesn't actually disable _all_ interrupts). > 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. Yes, it is really per-cpu and only kept in the thread structure as an optimization. It doesn't even need to be accessed (even for write) only withing critical sections, since it has the property of not being changed significantly by interrupt handlers -- intr handlers may change it up and down, but they must restore it to the value that it had when interrupt context was entered. This it is non-volatile as far as non-interrupt code can tell. Bruce 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?20030211002023.C1011-100000>