DragonFly kernel List (threaded) for 2007-01
DragonFly BSD
DragonFly kernel List (threaded) for 2007-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Our SMP implementation scalability

From: "Dmitri Nikulin" <dnikulin@xxxxxxxxx>
Date: Thu, 18 Jan 2007 09:26:32 +1100

On 1/18/07, Erik Wikström <erik-wikstrom@telia.com> wrote:
On 2007-01-17 16:31, Petr Janda wrote:
Even more interesting would be a guess of how good it might scale when
you finally get rid of BGL.

To memory-quote Matt, it should scale really well in theory, because most things are naturally lockless and so aren't co-dependent. FreeBSD scales badly (though improving) because there are complex locks everywhere, and even in the best case there's still a lot of data structures that end up making each CPU take turns. There's no way to make that scale well - the only clean solution is with replication and messaging like DragonFly is gaining. Linux has similar problems in theory, but has had so much more manpower applied to optimization that it performs very well anyway. FreeBSD is in a difficult position of not having an architecture that's easy to develop and optimize by few people (like DragonFly), and not having the manpower to fix consequences of a complex architecture (like Linux). That's not to say it's a bad system for low end SMP, but I doubt we'll ever see it utilize 1024-core servers very well.

I'm interested to know how NetBSD's SMP is going to evolve, because I
haven't heard much about it at all. What they have now seems to be the
same giant lock that FreeBSD 4 had, which means the kernel won't
scale. However, in my benchmarks on a dual core, the userland M:N
threading 'scales' as well as it possibly could for two cores (at
least 2x throughput, compared to the same user threads on one kernel

Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia

email: dnikulin@gmail.com

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]