Date: Sat, 17 Mar 2001 08:58:06 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: Proposal for the CPU interrupt API Message-ID: <Pine.BSF.4.21.0103170846230.16222-100000@besplex.bde.org> In-Reply-To: <XFMail.010316113801.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Mar 2001, John Baldwin wrote: > On 16-Mar-01 Bruce Evans wrote: > > On Thu, 15 Mar 2001, John Baldwin wrote: > >> ... Thus, I'm proposing to change > >> disable/enable_intr to return the previous state in addition to setting > >> the state. > > > > This would be a minor pessimization on i386's. WHether it is an optimization > > or a pessimization is very MD. It would be a major pessimization on i386's > > with ICUs if we put the entire interrupt state including the ICU masks in > > the interrrupt state. > > I don't think this needs to go near the ICU state, but yes, it is a minor > pessimization on i386. But on some machines it might need to go near something expensive like the ICU state. > >> This then removes the need for save_intr(), and > >> restore_intr() can stay the same. > > > > This doesn't remove the need for save_intr(). I use it in at least one > > place (perhaps only one :-) where I don't want to disable interrupts any > > more than they already are. > > If it is just the CPU status, then just intr_disable() (or disable_intr()) > will accomplish this. I don't use disable_intr() since it has the unwanted side (actually main) effect of disabling interrupts. > > It's really a mistake to let this stuff escape from MD code. Frotunately, > > it hasn't escaped far yet. > > The only somewhat MI place it is used is in the bowels of the mutex code. Any > MI code that wishes to prevent preemption should use a spinlock instead of > disabling interrupts manually now. It is also used in (non-broken) drivers that use fast interrupt handlers. The broken sio and cy drivers in -current assume that spinlocks disable all interrupts (on the current CPU). This will be fixed. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0103170846230.16222-100000>