Date: Mon, 11 Mar 2002 10:34:26 -0800 From: Michael Smith <msmith@freebsd.org> To: Bruce Evans <bde@zeta.org.au> Cc: smp@FreeBSD.ORG Subject: Re: Interrupt Context becomes a misnomer (was Re: Core recognizes SMPng tech lead ) Message-ID: <200203111834.g2BIYQ301091@mass.dis.org> In-Reply-To: Your message of "Mon, 11 Mar 2002 19:39:33 %2B1100." <20020311190003.W5788-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > We should stop doing (almost) anything in "interrupt context". An > > interrupt handler should at most: > > > > - pacify the interrupting device > > - make the driver's interrupt thread runnable > > This is insignificantly different from what happens for non-fast interrupts > now in -current: Understood. The point I was trying to make is that "interrupt context" and the process of blocking interrupts should largely vanish. > We depend on icu/apic masking to keep the device quiet while we are > running higher-priority things. icu/apic masking also prevents other > devices that are sharing an interrupt from even interrupting, so we > cannot in general support devices that need pacifying real soon in > real-time. This is a platform constraint, and unlikely to go away soon. > We would need immediate pacification to support such > devices and/or hardware without an icu/apic, but this would require > rewriting the interrupt system yet again The scheme proposed will allow for closer to optimal behaviour in the APIC case where the vector is not shared (common) or the ICU case where the interrupt is not shared, by allowing the driver to establish a private 'fast' handler to provide this immediate pacification. > and wouldn't significantly > uncomplicate the new-bus-related locking: a single lock can lock out > all the current hardware ithreads just as well as it can lock out > all software ithreads, and would work equally poorly (if it is held > for long) for both. Newbus' lock would never be acquired in "interrupt context", and one would not acquire the lock to block interrupts. > Fast interrupt handlers are basically handlers that follow this model. > I wouldn't want to use them for all interrupt handlers because they > (or rather the code that shares data with them) is harder to write. > But locking may require similar complications anyway (you can't just > access your data but you have to lock it, and you must only lock it > for short intervals to not defeat the point of having fast interrupt > handlers/ immediate pacification. The whole driver must be aware of > the real-time constraints of the hardware part of of interrupt handler). Typically the data the fast handler needs to touch is invariant; the one item not fitting this description is the mechanism that the fast handler uses to feed tokens from the hardware to the soft handler. This is why I made such a deal a while back about lockless, mp-safe queue algorithms. If such an animal exists, it would serve us well to standardise on something that will let us pass even just a set of (void *) up a queue. Many peripherals want you to empty their output queue before they will stop interrupting; for a fast handler to be effective in this context, it needs to be able to put the tokens off this queue somewhere. > (I think SWI > handlers should be able to access hardware, at least if if they lock > out there hardare interrupt handler -- this is not much different from > hardware accesses in non-interrupt context to initiate i/o.) How would you best propose to implement this interlock? I'm guessing that for most hardware accesses, a well-placed spinlock would do, but then I can think of some peripherals where that wouldn't necessarily be adequate, due to spinning waiting for the hardware. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt 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?200203111834.g2BIYQ301091>