Re: Our SMP implementation scalability

["Dmitri Nikulin" <dnikulin@xxxxxxxxx>]

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
thread).

---
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia

email: dnikulin@gmail.com