Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Feb 2002 22:36:14 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Bob Van Valzah <Bob@Talarian.Com>
Cc:        Robert Watson <rwatson@FreeBSD.ORG>, Jorge Aldana <jorge@salk.edu>, Garance A Drosihn <drosih@rpi.edu>, <smp@FreeBSD.ORG>
Subject:   Re: Performance vs. Stable
Message-ID:  <20020227220832.V48463-100000@gamplex.bde.org>
In-Reply-To: <1014781427.15635.10.camel@Relent.Bob.WhiteBarn.Com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 26 Feb 2002, Bob Van Valzah wrote:

> On Tue, 2002-02-26 at 19:50, Robert Watson wrote:
> > It's worth noting that WITNESS can have a dramatic impact on performance.
> > I actually turned it off by default recently, and it got turned back on
> > again (for good reasons).  Any benchmarking must be done without those
> > settings turned on.
>
> Allow me to quantify the difference and show a more valid comparison to
> -STABLE as well.
>
> 		(Best numbers are starred, i.e., *123)

You should use a more recent version of lmbench, but you might be
rediscovering wheels here.  John Dyson used lmbench many years ago to
motivate large optimizations in vm.  I have used an alpha version of
lmbench2 since 1997 and have a database of about 100 files for interesting
milestones.  I must have run it thousands of times.  The web site
pointed to at the beginning of this thread has a not-so-alpha version.
It is a bit nicer than the 1997 version (it now gives times in nanoseconds
which is very necessary for current CPUs), but I haven't switched to
it because it can't parse my database.  The 1997 version is much nicer
than lmbench1.  It runs much faster and proces much better output and
has many relatively minor improvements in the basic benchmarks.

>
>         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     3.1     2.8     2.8  4.2
> 3.7    4.9
> TwinHead  FreeBSD 4.5-S  228     6.1     2.2     1.9     1.9  2.4
> *27    *30
> TwinHead. FreeBSD 5.0-2  233     *10   *1.7K   *7.3K  *12.6K  *51
> 1.7    3.6
>
> The top line is -CURRENT with WITNESS and friends turn on. The bottom
> line is -CURRENT with them turned off. The middle line is -STABLE.
>
> I'm surprised by the results here. (Maybe I'm misinterpreting them?) It
> looks like -CURRENT is over 6x faster than -STABLE on null system calls.
> Forks and mmap seem about 2x faster but context switches are slower.

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.

> It's interesting to note that WITNESS and friends slowed down null
> system calls by 11x and other kernel operations by about 3-5x.

This is because the null system call spends most of its time doing
locking and WITNESS mostly witnesses locking.  Most syscalls take
relatively longer to do useful work that is not slowed down much
by WITNESS.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020227220832.V48463-100000>