Date: Wed, 20 Nov 1996 15:35:26 -0700 From: Steve Passe <smp@csn.net> To: Peter Wemm <peter@spinner.dialix.com> Cc: cbrown@aracnet.com, Barney Wolff <barney@databus.com>, freebsd-smp@freebsd.org Subject: Re: reinventing vs copying Message-ID: <199611202235.PAA27430@clem.systemsix.com> In-Reply-To: Your message of "Thu, 21 Nov 1996 06:15:33 %2B0800." <199611202215.GAA13894@spinner.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
>Hmm, there are three ints that the docs mention from memory, aren't there?
> I think it was IRQ0(timer), IRQ8(rtc) and IRQ13(dma chaining/FPU). IRQ 8
>is 'essential' (it drives process resource usage and profiling). We don't
>care about IRQ13 from memory.
no, only 2, IRQ0 and IRQ13. IRQ8 originates on the RTC chip, and thus is
not localized to the same piece of silicon as are 0/13.
I agree about IRQ13, only need would be by NON-busmaster EISA cards that
use the EISA DMA chaining INT (ie INT13). So I guess it means my latest hack
that supports this should be cleaned up and committed after you finish the
merge, at least as a documented TEST in smptests.h
To use it we would then need to define the final hardclock INT to either:
1: be sent to the boot CPU,
which does the global work,
and sends IPIs to all APs to let them do their per-CPU hardtick work.
2: be sent to all CPUs (ie broadcast),
each of which does their per-CPU work,
and the boot CPU realizes it also needs to do the global work.
It would be nice if the same hardclock INT code be used reguardless
of whether it comes via IRQ2 or via the 8259/IRQ0. If however, we find
that the IRQ2 (most common) case has to be compromised to support the
other, we could write 2 versions and plug in the address in the already
existing re-direction variable.
---
>Neither.. Just have the interrupt serviced.. It or's it's bit in
>_ipending and returns since it's masked. If you have multiple interrupts
>during the handler execution, the effect is that the bit is set multiple
>times. Bruce profiled this and found that this was "insignificant" from
>memory (it happens something like the order of a fraction of a percent of
>cases).
>
>That way, we simply don't loose the edge interrupt, since we will see that
>another one arrived. (of course, this depends on exactly when the bit in
>_ipending is cleared)
I need to really read Bruce's changes that I incorporated into vector/icu
to see if this is what we are already getting...
--
Steve Passe | powered by
smp@csn.net | FreeBSD
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE
04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX
WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR
tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+
=ds99
-----END PGP PUBLIC KEY BLOCK-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611202235.PAA27430>