SMP on FreeBSD 6.x and 7.0: Worth doing?
Brett Glass
brett at lariat.net
Mon Dec 24 07:49:51 PST 2007
At 07:14 AM 12/24/2007, Scott Long wrote:
>Brett,
>
>There could be several problems here:
>
>1. WITNESS, INVARIANTS, malloc debugging. Are any of these turned on for you? I don't recall if malloc debugging got turned off yet for the
>7.0 snapshots.
I nuked debugging when I recompiled the kernel with SCHED_ULE.
>2. Disk subsystem. What kind of disk controller are you using? Not all
>drivers work well in FreeBSD. Are linux and freebsd using identical
>hardware?
They were. The drives are SATA.
>3. Directory hashing. If you're using squid, you __must__ tune the DIRHASH, otherwise you'll spend a lot of time doing pathname lookups. What filesystem is linux using?
Whatever comes standard with Ubuntu. As for directory hashing: Squid doesn't
use more than 256 entries in each one, so that's what I normally set. I
also normally do a newfs with parameters that favor the distribution of
object sizes found in Web caches. (We did this on both Linux and FreeBSD.)
>Would you mind if I logged into your test system and looked around to
>help diagnose the problem?
The system isn't online now, because it's been a week since the tests and
I also wanted to try the 6.3 beta and a few hardware changes.
My guess, based on what I saw, is that UFS2 doesn't take as much advantage of
SMP as Linux's file system does and threads are blocking on file I/O.
(Networking does not seem to be the botteneck, though I have heard that the
IP stack in 7-CURRENT needs optimization and that this had been proposed as
a sponsored project.)
--Brett
P.S. -- If the chip manufacturers were not making it so that one needs to
go to SMP to get more processing power, I wouldn't be doing SMP. I'd rather
use FreeBSD 4.11 on a single core "gaming" CPU, as I did a few years ago
when I needed a very fast server. But this isn't a viable option nowadays....
More information about the freebsd-stable
mailing list