Date: Mon, 24 Jul 2000 09:16:43 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Greg Lehey <grog@lemis.com> Cc: Chuck Paterson <cp@bsdi.com>, Bruce Evans <bde@zeta.org.au>, David Greenman <dg@root.com>, freebsd-smp@FreeBSD.ORG Subject: Re: : ipending (was: SMP progress (was: Stepping on Toes)) Message-ID: <200007241616.JAA41009@apollo.backplane.com> References: <200007221620.JAA29862@apollo.backplane.com> <Pine.BSF.4.21.0007230257270.810-100000@besplex.bde.org> <200007221657.KAA20309@berserker.bsdi.com> <200007051652.KAA14768@berserker.bsdi.com> <20000722185705.A10221@wantadilla.lemis.com> <200007221620.JAA29862@apollo.backplane.com> <20000724124520.F82241@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:This happens on every interrupt, and as Bruce points out, the writes
:take a long time. By comparison, the code I have now is much shorter
:and contains only the minimum 1 outb instruction:
:
:Xintr3:
: pushl $0
: pushl $0
: pushal
: pushl %ds
: pushl %es
: pushl %fs
: mov $0x10 ,%ax
: mov %ax,%ds
: mov %ax,%es
: mov %ax,%fs
: movb $0x20 ,%al
: outb %al,$0x020
: incb intr_nesting_level
:Xresume3:
: pushl 3 IRQ number
: sti
: call sched_ithd
: jmp doreti
:
:sched_ithd is pretty close to the BSD/OS code. I've left the
:debugging code and some comments out of this version:
This will fail utterly. First, it will fail for level triggered
interrupts. Second, there is a massive race condition if a new
interrupt occurs while the interrupt thread is already running...
in that case the interrupt thread will not be restarted when it
is through processing the first one (for the same interrupt source).
Easily half of our interrupt routines expect that to work properly.
The ipending stuff in my code sample takes care of that case, as does
the current masking code.
I would strongly recommend that you not spend time trying to optimize
the already reasonably optimal interrupt masking. I've gone over that
code a hundred times in the last year (because I don't like the mess
either), but frankly there is no way to do it better. And I'm sure
Bruce has too.
-Matt
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?200007241616.JAA41009>