Date: Mon, 11 Mar 2002 19:39:33 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Michael Smith <msmith@FreeBSD.ORG> Cc: "M. Warner Losh" <imp@village.org>, <smp@FreeBSD.ORG> Subject: Re: Interrupt Context becomes a misnomer (was Re: Core recognizes SMPng tech lead ) Message-ID: <20020311190003.W5788-100000@gamplex.bde.org> In-Reply-To: <200203080211.g282BAt01489@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Mar 2002, Michael Smith wrote:
> (moved to smp@)
>
> > This can be described as "newbus doesn't change often enough to do
> > anything other than one big lock around it." However, I must admit
> > that I've not thought through the implications of devices arriving and
> > leaving at interrupt context.
>
> I've been talking about this with various people, but here's a good point
> at which to bring up something that folks working on device drivers
> should think long and hard about.
>
> 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:
- make the driver's interrupt thread runnable
- [possibly do other higher-priority things]
- run the driver's interrupt thread, which normally pacifys the
interrupting device as one of the first things it does.
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. 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 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.
> Now, before you all start screaming about "fast interrupts", yes, there
> are a few devices that require special treatment. But there aren't many
> of them, and they can be accomodated in this model (by doing slightly
> more in the interrupt handler).
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).
> In the case where a device can't be "pacified" without considerable work
> (this is fairly rare), the handler can return status indicating that the
> interrupt should be masked until the thread has run.
>
> You can turn the concept on it's head and view it as making every driver
> have a "fast" interrupt handler. "Slow" handlers go away, making the
> issue of handling things "in interrupt context" much less of a problem,
> since almost nothing (clock code notwithstanding) is called from
> interrupt context.
This is sort of what we do now: every device without a fast interrupt
handler has a near-null hardware interrupt handler that says that the
interrupt should be masked. Eventually, we switch to a software
interrupt handler that happens to access the hardware. (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.) There is
no data shared between the fast interrupt handler and the rest of the
driver, so the locking for this is especially simple. However, the
"software" part of the handler may need considerable locking to
protect the data from non-interrupt accesses.
> This isn't a particularly novel approach; Apple use it, BSD/OS is likely
> to go this way, and it's strongly encouraged by the IA64 interrupt model.
> I'm sure that plenty of other systems do things this way as well; I just
> don't have the research hours to track them down.
Two-bit micros probably used it since they couldn't afford the
sophistication of the current model :-)
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?20020311190003.W5788-100000>