"The NetBSD Foundation announces that it has hired Andrew Doran to work full-time on improving symmetrical multi-processing in NetBSD. This work is made possible through a generous donation by Force10 Networks and internal funding by The NetBSD Foundation. Andrew Doran is an independent, Dublin based Unix systems consultant with special interest in building scalable systems. He has been a NetBSD developer since 1999 and is currently working on the transition from a big-lock SMP implementation to a fine-grained model, which allows multiple CPUs to execute code in kernel context simultaneously. Hiring Andrew full-time will boost work in this area, with the final result of a SMP implementation that is ready for tomorrow's multi-core-CPUs."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-07-15
>and OK on FreeBSD 6.2 but I can't verify this to be true without seeing benchmarks.
Linux scheduler has got some peaks, but FreeBSD 6.x scheduler, 4BSD, has got reliability under heavy load. With the advent of the new CFS scheduler in Linux (2.6.23), Linux says good bye to "peak-nonsense" and says hello to reliability instead of benchmark mumbo jumbo to impress media. So CFS is in fact almost equal now to 4BSD.
http://jeffr-tech.livejournal.com/10103.html
Member since:2005-07-11
Member since:2007-07-25
FWIW, the apparent poor Linux performance is due to a bug in the glibc malloc implementation. Should be patched in 2.5, or you can use the google malloc library.
http://ozlabs.org/~anton/linux/sysbench/
Member since:2006-02-01
Just to let you know that the issue still remains. The new CFS sched really helps, though it doesn't have as great of a peak but is more reliable under load.
Check this out, even with the "fixed" glibc malloc and even with CFS.
http://people.freebsd.org/~jeff/sysbench.png
Member since:2006-04-17
DragonflyBSD apparently doesn't do so well at scaling
at the moment.
http://obsecurity.dyndns.org/dfly.png
http://leaf.dragonflybsd.org/mailarchive/users/2007-05/msg00134.htm...
Member since:2005-08-10
DragonFly would be sure to disappoint at the moment as large chunks of it still require and run under the MP lock, including the threading code.
My best guess ATM is that its going to be another year before we start to see the MP lock removed from enough of the kernel to see how well the DF model scales.
I'm optimistic that it should do well once the MP lock is largely gone, but that's off in the future.
Member since:
2005-12-31
Yes it'd be nice to see some new benchmarks. I don't believe anyone has done anything more recent.
I believe SMP is somewhat weak on NetBSD & OpenBSD and OK on FreeBSD 6.2 but I can't verify this to be true without seeing benchmarks.
FreeBSD 7 will give a *real* boost to SMP performance & turn things around.
A couple of benchmark results provided by FreeBSD:
http://obsecurity.dyndns.org/bind-resperf.png
http://people.freebsd.org/~jeff/sysbench.png
http://people.freebsd.org/~jeff/mysqlwrite.png
http://people.freebsd.org/~jeff/scaling.png
The performance difference in SMP bind from 6.2 to 7 seems VERY IMPRESSIVE.
Another short article talking about SMP on FreeBSD:
http://www.internetnews.com/dev-news/article.php/3561526
I'm hoping someone will provide independent SMP performance benchmarks once FreeBSD 7 is released. And compare it to NetBSD, OpenBSD, DragonFly & Linux.
Though DragonFly is not one of the popular choices I'd like to see how it performs because it is handling SMP differently. ( more out of interest ).