From owner-freebsd-smp Sun Apr 27 22:53:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA24711 for smp-outgoing; Sun, 27 Apr 1997 22:53:34 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA24706 for ; Sun, 27 Apr 1997 22:53:32 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id BAA10889; Mon, 28 Apr 1997 01:51:21 -0400 Date: Mon, 28 Apr 1997 01:51:20 -0400 (EDT) From: Ben Black To: Chuck Robey cc: FreeBSD-SMP@FreeBSD.org Subject: Re: SMP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > I'm confused, then. If there's only one kernel, then only one cpu can > run it, so only one cpu can field the system calls. If both cpu's can > field system calls, then unless they contact the other one to get the > work done, then there must be two copies of the kernel ruinning, right? > > I'm probably misunderstanding something. Maybe you meant only one piece > of software called "kernel" but two cpus running it? > hence my saying one kernel. there is a single kernel image in memory and both CPUs execute different (or the same) parts of it at the same time. the single lock is to keep the CPUs from stepping on each other. when one CPU wants to access a shared resource (and pretty much everything in the kernel is considered shared) then it acquires the mplock, does its business, releases the lock and continues. if the other CPU has the lock when one wants to acquire it, the second CPU waits. one kernel, one lock. b3n