Date: Wed, 03 Dec 1997 16:47:45 -0700 From: Steve Passe <smp@csn.net> To: Joe Eykholt <jre@Ipsilon.COM> Cc: smp@freebsd.org Subject: Re: SMP Message-ID: <199712032347.QAA10070@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Wed, 03 Dec 1997 15:15:01 PST." <3485E7F5.15FB7483@ipsilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > 5. The APIC vectors need to be re-arranged into a priority order so > that interrupts > don't need to access the I/O APIC to mask off the interrupt during > handling. > (Or maybe there's a better way to do this). I noticed that > level-sensitive > interrupts are getting taken twice, because the first interrupt only > masks with CPL, > so after the EOI and sti, the interrupt is still pending and is taken > again. Only > the second time does it get masked in the I/O APIC. Being a central sounds like you are describing our "lazy masking" an attempt to skip blocking an INT unless we get hit a second time. If what you are saying about the second hit being automatic is true, its something for me to tackle real soon. Have you actually demonstrated this to occur all times? Or just ocassionally? OR just via code examination? Could you descibe a specific example that would help me grok the specific situation? > resource, locking > the IOAPIC on every interrupt is unacceptable, so restructuring the > interrupts in > a priority order and deferring the EOI until the end seems necessary. I > don't > completely like this, so I'm hoping there's a better way. I think INT priority ordering will need to be reserved for "execution priority" as oppossed to critical region protection. I'd like it to be dynamic, ie priorities set at boot time as oppossed to compile time. I definately like the idea of using kernel threads to execute ISRs, as oppossed to the current model of running them in the context of whatever process gets hit by the INT. Just not sure how pratical this would be. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712032347.QAA10070>