Date: Sun, 23 Jul 2000 03:36:39 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Greg Lehey <grog@lemis.com>, Chuck Paterson <cp@bsdi.com>, David Greenman <dg@root.com>, freebsd-smp@FreeBSD.ORG Subject: Re: ipending (was: SMP progress (was: Stepping on Toes)) Message-ID: <Pine.BSF.4.21.0007230257270.810-100000@besplex.bde.org> In-Reply-To: <200007221620.JAA29862@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 22 Jul 2000, Matthew Dillon wrote:
> :In a similar way, I'm removing interrupt mask copies in memory. We
> :still mask interrupts which aren't in use, but no others. If anybody
> :has any reason not to want to do this, we should talk about it.
> :
> :Greg
That would be wrong. The interrupt masks are kept in memory because it
is much faster to access them there. Several hundred times faster than
PIC accesses on current machines. When I implemented this on 1992's
machines, the memory copies were less than ten times faster. The APIC
case is not as bad. I don't know the details of it.
> I think you still have to mask level interrupts, otherwise you won't
> be able to sti. Some subsystems may generate a phenominal number
> of interrupts while the interrupt routine is running -- for example,
^^^ another
> the serial ports. I think the masking was put in there as an
E.g., one serial port interrupting every 87 usec gives about 50
interrupts while the keyboard interrupt handler is busy-waiting to
program the keyboard LEDs.
> optmiization not only for that, but also so the interrupt could be
> EOI'd early so as to allow a new interrupt to become pending while
> the interrupt routine was running (thus closing a potential window of
> opportunity where an interrupt might otherwise be missed).
This only works right for interrupts other than the one being handled
(we guarantee not to miss other interrupts provided they are live for
at least the few usec needed for interrupt processing before the EOI).
Masking the current interrupt prevents ipending getting set for it, and
there is race to exit from the interrupt handler and clear the masks so
that a new transient interrupt can be seen before it goes away. We
certainly lose this race in some cases, e.g., when the exit is interrupted
by another interrupt handler than takes too long. I suspect that most
"stray" interrupts are caused by losing this race.
> If you remove the masking you have to delay the EOI and that is probably
> a huge mistake because it may lead to lost interrupts. Another example:
> if a keyboard interrupt is lost you can lose the keyboard entierly. If
This doesn't seem to be a problem in practice. I think the keyboard
controller times out and sends a new interrupt.
> the EOI is delayed there is a much greater chance of losing the keyboard
> interrupt.
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?Pine.BSF.4.21.0007230257270.810-100000>