Re: Performance 4.x vs. 6.x

[bsdude@xxxxxxxxxxxxxxx]

This is the last time I will post about this (and (I do appreciate Matt?s
patience with this thread).. Just a couple quotes from Peter Wemm about
the code base pollution/complexity/lack of scalability in the
FreeBSD-current code base. This is not part of a flame-fest but discussion
about scalibility issues. That is what makes the current DF effort very
exciting to see the progress that has been made in the last year!
G


<>
At BSDCan, I tinkered with a checkout of the cvs tree, to see what the
kernel side of things would look like if M:N support came out.  The
result is an amazing code clarity improvement and it enables a bunch of
other optimizations to be done with greater ease.  Things happen like
being able to easily reduce the C code executed between an interrupt
and ithread dispatch by about 75%.  This simplification enabled Kip to
do a bunch of scalability work as well (per-cpu scheduling locks,
per-cpu process lists, etc).


Speaking of scalability, 16 and 32 way systems are here already and will
be common within 7.0's lifetime.  If we don't scale, we're sunk.  My gut
tells me that we HAVE to address the complexity that the KSE kernel code
adds in order to improve this.  We can barely work well on 4-cpu systems,
let alone 32 cpu systems.
<>


>
> Taking Matt's reply under advisement, all I'll point out is that it's
> not reasonable to treat "FreeBSD 6.x" in the same class as "5+"; FreeBSD
> 6.x is where we fixed most of the problems that afflicted the
> 5.x branch, and based on the thousands of hours of optimization and
> stress-testing we've put into it, it's easily the most stable and in many
> areas the most performant branch of FreeBSD ever.  If you had bad
> experiences with FreeBSD 5.x, don't write off 6.x until you've tried it.
>
> Kris
>
>