Re: Performance 4.x vs. 6.x

[Kris Kennaway <kkenn@xxxxxxxxxxxxxxxxxx>]

On 2006-10-14, bsdude@xxxxxxxxxxxxxxx <bsdude@xxxxxxxxxxxxxxx> wrote:
> 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

If you're going to quote, don't quote out of context :).  Peter is
referring to the complexity of the kernel thread support ("KSE") and
not universal "pollution/complexity/lack of scalability in the
FreeBSD-current code base".

FYI, I'm quite involved in the scalability work quoted below, so I'm
well aware of the status of FreeBSD as it compares to previous
versions, and prospects for future optimizations :-)  As Peter says,
the focus is now on scaling beyond 4 CPUs, which is something that
could not be achieved on older releases including FreeBSD 4.

Anyway, further discussion about the limitations or otherwise of FreeBSD
should take place on a FreeBSD mailing list where it's not off-topic.

Kris

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