From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 1 06:38:00 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CB2216A4CE for ; Thu, 1 Apr 2004 06:38:00 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26B7B43D41 for ; Thu, 1 Apr 2004 06:38:00 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i31EbtPq012962; Thu, 1 Apr 2004 09:37:55 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i31EbtCO012959; Thu, 1 Apr 2004 09:37:55 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 1 Apr 2004 09:37:55 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Bjoern A. Zeeb" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: implications of SMP kernel on UP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2004 14:38:00 -0000 On Thu, 1 Apr 2004, Bjoern A. Zeeb wrote: > what are the implications on running an SMP enabled kernel on a UP > machine ? > > I first thought of things like: > - performence (most likely not worth the discussion ?) > - additional locking problematic ? > - ... ? > > Or asked the other way round: why would I want to disable SMP on a > kernel that is going to run on a UP machine ? I've observed substantial performance overhead from enabling SMP on UP boxes. However, increasing numbers of "UP" boxes ship with HTT, blurring the picture a little. There are at least two issues associated with enabling SMP on UP boxes: - First, we use the IO APIC, which has caused compatibility problems with some systems (likely actually ACPI problems?), as well as a slightly higher cost to interrupt handling. - Second, we use locked operations for locks, increasing their cost. I've spent a bit of time trimming some gratuitous locking from the system call path, so it should actually be a bit better than it was previously, but the upshot is that if you want optimal performance on UP, you should compile out both apic and SMP. Peter and I have had conversations about creating "HAL" modules that plug and play locking operations, optimized copies, and so on for the kernel, and improving the run-time pluggability of SMP (et al), but haven't made any progress. It's worth noting, FYI, that we always compile modules with locked atomic operations so that one module will work on UP and SMP... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research