From owner-freebsd-smp Thu Sep 12 11:11:05 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA19994 for smp-outgoing; Thu, 12 Sep 1996 11:11:05 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA19989 for ; Thu, 12 Sep 1996 11:11:04 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA07176; Thu, 12 Sep 1996 11:07:22 -0700 From: Terry Lambert Message-Id: <199609121807.LAA07176@phaeton.artisoft.com> Subject: Re: Intel XXpress - some SMP benchmarks To: peter@spinner.dialix.com (Peter Wemm) Date: Thu, 12 Sep 1996 11:07:22 -0700 (MST) Cc: smp@csn.net, rv@groa.uct.ac.za, freebsd-smp@FreeBSD.org In-Reply-To: <199609120640.OAA02113@spinner.DIALix.COM> from "Peter Wemm" at Sep 12, 96 02:40:41 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > One thing I'm not clear about from the IO apic docs yet is whether there > are 15 cpu's and 15 IO apic's, or whether there's a limit of 15 devices on > the APIC bus. 1 BP, 31 (AP | IO APIC) (2^5 == 32) > Incidently, in one of the books that I did find when I was looking some > time ago, it mentions that with the MESI caches in action, write-through > was "for speed" (to avoid cache conflict resolution cycles or something) > versus write-back and may be required for correct multiprocessor > operation.. I'm not sure I trust the book on that, as it's only got a > very slim section on the apic and multiprocessing (no detail at all) and > is quite cryptic and (I think) self contradicting in places. Naturally I > cannot find the reference, so I'm denying this comment exists. :-) Depends on whether page updates are propagated to all processors in the writeback case, or only the one that initiated the event (or handled it). Correct hardware should work with writeback. BTW, with MESI, IMO, *only* writeback asures you that you don't have to dump IPI's to the other processor if you are a processor which gets an invalidate. I suppose there is a lot of broken hardware out there, however. Means we should be prepared to handle it in software in all cases, and that writeback should be a non-default option. 8-(. There are ways to test for writeback viability, but they are about as complicated as those you would use to test DMA transfer ranges on EISA or cache notification on Saturn I, Neptune I, Mercury I, and VLB chipsets (ie: complicated and in need of driver mods for all DMA drivers). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.