Date: Thu, 1 Apr 2004 09:37:55 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-hackers@freebsd.org Subject: Re: implications of SMP kernel on UP Message-ID: <Pine.NEB.3.96L.1040401093436.3849B-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.53.0404010704010.15681@e0-0.zab2.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040401093436.3849B-100000>