From owner-freebsd-smp Mon Apr 28 10:26:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA26139 for smp-outgoing; Mon, 28 Apr 1997 10:26:19 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA26134 for ; Mon, 28 Apr 1997 10:26:16 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA02110; Mon, 28 Apr 1997 10:24:57 -0700 From: Terry Lambert Message-Id: <199704281724.KAA02110@phaeton.artisoft.com> Subject: Re: SMP To: chuckr@mat.net (Chuck Robey) Date: Mon, 28 Apr 1997 10:24:57 -0700 (MST) Cc: black@zen.cypher.net, FreeBSD-SMP@FreeBSD.org In-Reply-To: from "Chuck Robey" at Apr 27, 97 11:03:38 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 > > freebsd-smp is not the best example of how to do SMP. it uses the > > simplest method: one giant kernel lock. i don't know that it is > > particularly representative of advanced SMP operating systems (though > > linux also uses a giant kernel lock). > > One per CPU? One lock total? How many copies of the kernel are running > at once? How is caching handled, per cpu, or globally (forcing the two > cpu's to look like one?) When a system call executes, what handles it, > one cpu? Think of processors as schedulable resources. Only one processor is allowed to be in the kernel at a time. It's SMP in that: o Any CPU can service an interrupt, fault, or system call o All CPUs can run at the same time as long only one of them is in the kernel So it's symmetric, but it is far from the fine grain parallelism that would be necessary to get the most out of additional processors. It is probably reaching it's break point at 4 (or even 3) processors, where it's no longer valuable to add more processors. Compare this to Sequent's Dynix, which scales well to 32 processors, or Thinking Machines, which scales into the thousands of processors. Heck, the FS code is basically non-reentrant; UnixWare 2.x got a 60% improvement in the the UFS (FFS) performance just by allowing kernel preemption and FS reentrancy. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.