From owner-freebsd-current Tue Apr 6 2:16:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (Postfix) with SMTP id 8CFE7151C4 for ; Tue, 6 Apr 1999 02:16:37 -0700 (PDT) (envelope-from will@ns.oeno.com) Received: (qmail 18296 invoked by uid 1001); 6 Apr 1999 09:14:38 -0000 To: dyson@iquest.net Cc: current@freebsd.org Subject: Re: SMP users (important) References: <199904031316.IAA45781@y.dyson.net.newsgate.clinet.fi> From: Ville-Pertti Keinonen Date: 06 Apr 1999 12:14:37 +0300 In-Reply-To: "John S. Dyson"'s message of "3 Apr 1999 16:16:28 +0300" Message-ID: <86wvzqm7pe.fsf@not.oeno.com> Lines: 47 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "John S. Dyson" writes: > I just wanted to "chime in" and say that the new patches are based > on a really good concept, and is much cleaner than the previous > method. Also, many RISC architectures can utilize this > method due to the availability of lots of general registers. > (One could go so far as to have the compiler reserve the > register.) Non-threaded user mode apps could optionally > use the reserved register, but for threaded user mode apps, > that reserved register could also be used as a per-thread > base pointer. Reserving an arbitrary register can make binary compatibility with other systems more difficult. On the i386 it isn't bad since only a few horribly machine-dependent programs might use %fs for anything. Something to look at as a precedent for other processors should be what commercial Unix systems on various non-i386 processors do. > I believe that NT does the above (%fs for X86, and general > register for Alpha.) On PPC, there are several local, Digital UNIX does not reserve a register. Based on a quick check it would seem to be using a call to PALcode to find the thread-specific data. Note that this is nothing like a system call, it's much faster (something like 10 clocks). > per-processor registers that one could use (but loading a > general register with that per processor register would be > needed for access.) Also, since the PPC has lots of registers, > one could? permanently reserve one of the general registers (r13?). I really don't like the idea of breaking the normal language conventions for any processor. For the i386, the use of segment registers is not relevant to C language conventions, but reserving a general register on any architecture should, IMHO, be avoided if at all possible. > All in all, this change has the potential for better context > switching time (and less memory/better performance for multi-threaded I believe that having meaningful values context-switched in segment registers can add context switch overhead. It shouldn't be significant, though. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message