From owner-freebsd-smp Sun Apr 27 22:30:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA23439 for smp-outgoing; Sun, 27 Apr 1997 22:30:39 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA23434 for ; Sun, 27 Apr 1997 22:30:37 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id XAA24002; Sun, 27 Apr 1997 23:30:32 -0600 (MDT) Message-Id: <199704280530.XAA24002@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Chuck Robey cc: FreeBSD-SMP@FreeBSD.org Subject: Re: SMP In-reply-to: Your message of "Sun, 27 Apr 1997 23:03:38 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 27 Apr 1997 23:30:32 -0600 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, > 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? We use the giant lock model at present. This is our biggest performance bottleneck, and it will soon change. More specifically there is one lock for the entire (SMP aspect of the) system. There is one copy of the kernel, which both CPUs can execute. The lock prevents more than one from running it at the same time. It is a spin lock, and is a counting lock, ie the possessor can get it mutiple times. cacheing is done by hardware enforcing the MESI model. I believe a system call will be handled by the CPU on which the calling process is running. An interrupt could be handled by any available CPU (simple answer, details are more complex). Caching is almost invisible to the software, we still have to handle TLB invalidations with inter-CPU interrupts. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD