From owner-freebsd-smp Mon Dec 16 10:33:25 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA23216 for smp-outgoing; Mon, 16 Dec 1996 10:33:25 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA23210 for ; Mon, 16 Dec 1996 10:33:22 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA01660; Mon, 16 Dec 1996 11:32:22 -0700 From: Terry Lambert Message-Id: <199612161832.LAA01660@phaeton.artisoft.com> Subject: Re: General SMP Design To: michaelh@cet.co.jp (Michael Hancock) Date: Mon, 16 Dec 1996 11:32:22 -0700 (MST) Cc: smp@freebsd.org In-Reply-To: from "Michael Hancock" at Dec 16, 96 11:47:20 am 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 > The other interesting things aside from NBS included CMDS, contention > minimizing data structures. > > They advocate per-processor pools which many agree is good for SMP > performance. It's more an issue of context migration and synchronization, and the impact on scalability. Many people who do not consider scalability (ie: a limit of 4 processors is acceptable to them) don't understand that the limit is imposed by synchronization arbitration. Per processor pools increase the number of processors you can do without hitting this limitation. For 2-4 processors, this limitation really does not impact performance enough to notice. After 4 processors, however, it becomes a real issue. So it's a post-scaling performance issue, or a scalability issue more than a pure performance issue. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.