Maybe Bruce's version of lmbench reports data differently that my (old)
version does? I was surprised by this too so I checked to make sure that
the numbers were absolute. My first round of test showed -CURRENT taking
10 ms while -STABLE took 61 ms for a "null" system call.
Alas when I went to verify my results by rerunning them on -STABLE, I
got different results. In fact, I got 10 ms. I guess I submit a paper to
the Journal of Irreproducible Results (www.jir.com) :-)
So here's the latest run:
(Best numbers are starred, i.e., *123)
Processor, Processes - factor slower than the best
--------------------------------------------------
Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc
8-proc
Syscall Process Process Process lat
ctxsw ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------
------
TH.Witnes FreeBSD 5.0-2 232 11 4.7 3.6 3.7 5.6
8.4 9.9
TwinHead FreeBSD 4.5-S 233 *10 *1.1K *5.6K *9.6K *38
*12 *15
TwinHead. FreeBSD 5.0-2 233 *10 1.5 1.3 1.3 1.3
3.9 7.2
The top line is -CURRENT with WITNESS and friends. The bottom line is
-CURRENT without WITNESS. The middle line is -STABLE.
So the way I'm reading it now is that (once you get WITNESS out of the
way) there's little difference in system call overhead between -STABLE
and -CURRENT. Lmbench "process" numbers seem 30-50% slower on -CURRENT.
The context switch numbers are still 4x to 7x slower on -CURRENT.
I've hooked back up with Larry and will be working with him (and I hope
Bruce Evans) to get a solid version of lmbench and procedures that lead
to more reproducible resutls.
Bob
On Wed, 2002-02-27 at 14:16, Kelly Yancey wrote:
> On Wed, 27 Feb 2002, Bruce Evans wrote:
>
> > >
> > > Processor, Processes - factor slower than the best
> > > --------------------------------------------------
> >
> > I think you are misinterpreting them. The non-starrd results are
> > absolute times. E.g., they say that the "null" syscall takes 6.1 usec
> > in 4.5-S and 6.1 usec in -current. This is about right. The "null"
> > syscall is actually a write of 1 byte to /dev/null. File i/o has been
> > been extensively pessimized in -current using locking. This only
> > matters much for small i/o's, which is exactly what the benchmark
> > tests. The pessimization is normally reduced a little for device files
> > by using devfs.
> >
>
> I know I am going out on a limb to doubt you, but are you sure? The chart
> header (as quoted above) sure seems to imply that the starred times are
> absolute and all of the others are relative comparisons. As such, I was quite
> impressed by how well -current appears to be performing compared to -stable
> given how little optimization has been done so far.
>
> Kelly
> kbyanc@{posi.net,FreeBSD.org}
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message