From owner-freebsd-smp Wed Nov 20 14:36:23 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA18415 for smp-outgoing; Wed, 20 Nov 1996 14:36:23 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA18410 for ; Wed, 20 Nov 1996 14:36:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA27430; Wed, 20 Nov 1996 15:35:26 -0700 Message-Id: <199611202235.PAA27430@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Peter Wemm cc: cbrown@aracnet.com, Barney Wolff , freebsd-smp@freebsd.org Subject: Re: reinventing vs copying In-reply-to: Your message of "Thu, 21 Nov 1996 06:15:33 +0800." <199611202215.GAA13894@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Nov 1996 15:35:26 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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-----