From owner-freebsd-smp Sun Nov 10 12:37:20 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA01560 for smp-outgoing; Sun, 10 Nov 1996 12:37:20 -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 MAA01541; Sun, 10 Nov 1996 12:37:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id NAA16738; Sun, 10 Nov 1996 13:35:32 -0700 Message-Id: <199611102035.NAA16738@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: Bruce Evans , smp@freefall.freebsd.org, nate@freefall.freebsd.org Subject: Re: cvs commit: src/sys/i386/isa syscons.c syscons.h In-reply-to: Your message of "Mon, 11 Nov 1996 01:33:35 +0800." <199611101733.BAA15722@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Nov 1996 13:35:32 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > Bruce Evans wrote: > > I'm going to replace the i586 optimized copying options (including the > > one for copyin/copyout that went away) by negative-logic npx flags. > > This is mainly for 2.2. I don't trust copying through the FPU to work > > on i586 clones. > > We currently have to #ifdef out the i586_bcopy on the SMP code which does > not yet understand the fact that there is more than one FPU involved... > (duh!) This probably explains why floating point is *extremely* > unreliable.. > > Just the same as we have to #ifdef out the pentium_microtime stuff, > although I must take a closer look again now that you fixed the problem of > masked-for-too-long clock interrupts.. There was some discussion a > while ago about having the 100Hz timer interleaved across all cpus in a > round-robin fashion, and if each cpu kept per-cpu smoothing/rate/etc > variables, it might just be able to cope with it with enough tweaks. this is currently available in SMP by using the APIC_IO option in the kernel config file AND NOT defining "TEST_LOPRIO" in i386/include/smptests.h. TEST_LOPRIO causes all INTs to be offered to all available CPUs via the "lowest priority" algorithm of the APICs. Without TEST_LOPRIO defined only the system clock INT is sent to all CPUs (assumming options APIC_IO is set). I guess this means that it is unpredictable as to which CPU gets the clock tick. We could do a psuedo round robin scheme by explicily reprogramming the target for that INT each tick, but the "masked-for-too-long clock interrupts" would still be a problem. This is out of my area of knowledge, but would it make sense to localize the tick service to one CPU, but make it aware that it needs to broadcast a "tick" IPI ("all but self" InterProcess Interrupt) to the APIC bus for puposes of context switch on the other CPUs? If the "per-cpu smoothing/rate/etc" is do-able it would be better in the sense that there would be less problem with INTerrupt latency. Still, we would need the "tick IPI" to guarantee good accuracy for the context switches on the other CPUs. And then there was talk of "per-process-variable time quantums"... -- Steve Passe | powered by smp@csn.net | FreeBSD