From owner-freebsd-smp@FreeBSD.ORG Sun Sep 19 17:19:04 2004 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87DDB16A4CE for ; Sun, 19 Sep 2004 17:19:04 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5EE243D55 for ; Sun, 19 Sep 2004 17:19:03 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i8JHIUN1020830; Sun, 19 Sep 2004 13:18:30 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i8JHITc4020827; Sun, 19 Sep 2004 13:18:29 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 19 Sep 2004 13:18:29 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <414D3A87.7080305@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-smp@freebsd.org Subject: Tried and tested SMP model (was: Re: ... blah blah ...) X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Sep 2004 17:19:04 -0000 On Sun, 19 Sep 2004, Julian Elischer wrote: > >>Furthermore, the SMP issue is a common problem among many FreeBSD > >>developers whom have told me the same, there is alot of this > >>information all over the > >>internet. FreeBSD is unable to perform good on multiple CPUs, > >>the fixes are just work arounds. > > What have they told you? SMP in FreeBSD is coming along quite nicely as > far as I see.. We now have native SMP scaleable threading in the default > system, and larger and larger parts of the system ara able to take > advantage of Multiple processors to parallelise their work. And our SMP/threading model is hardly unproven -- substantial parts of the architecture were based on the extensively documented experiences of the SunOS/Solaris SMP work, Mach SMP, SGI SMP, BSD/OS SMP, Linux SMP, etc. Many of these systems have demonstrated excellent scalability on SMP and NUMA systems (some would say: rediculous scalability), as well as make very effective use of processor affinity. While the work of re-writing a kernel to use explicit synchronization is pretty expensive, and work on the scheduler requires a lot of hard thinking, it's not as though we're exploring uncharted waters that might contain unidentified monsters. And the hardest part of the current SMP work isn't putting in the locking primitives, it's identifying and adapting the synchronization requirements of the components, which is work that has to be done regardless of what actual SMP model is suggested. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research