In message <20050223121503.483d7458@hal.xisop>Matthew Mondor writes

>Although only halfway on topic, since SMP related, but probably not
>driver related (but might be, since disk I/O seemed involved alot), I
>looked at these lately:
>
>http://software.newsforge.com/software/04/12/27/1238216.shtml?tid=152&tid=72&t
>id=29
>http://software.newsforge.com/software/04/12/27/1243207.shtml?tid=72&tid=29
>
>Although this is mesured using userspace daemon MySQL (with SA threads),
>although results were generally impressing for single processor systems,
>several looked suboptimal when SMP was used, unfortunately.  Also when
>large data was used, where I/O possibly was a bottleneck
>
>Unfortunately I do not have profiling data, nor did the author to back
>his claims and help discover the actual bottlenecks.  [...]

Thanks for the links. The results (second link; first link is just the
rationale, methodology and description of setups) are very interesting.

Comparing just the big-lock kernels: NetBSD-2.0 does better than
OpenBSD-3.6 or FreeBSD-4 on the single-CPU SuperSmack benchmarks.  But
NetBSD-2.0 has a significant degradation on a two-CPU setup (dual-CPU
about 10% slower than single), whereas FreeBSD-4 and OpenBSD are no worse.
I wonder what Nathan makes of that.

Re the poor showing in the large-IO benchmarks: didn't Bill Studenmund
recently (circa Jan 26) fix a bug whereby each fsync() ends up syncing
the entire disk?  That could easily explain the poor results on
I/O-bound tests, but I dont know if the problem was in 2.0, or just
-current.