Date: Wed, 26 Apr 1995 16:35:39 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, terry@cs.weber.edu Cc: geli.com!rcarter@implode.root.com, hackers@FreeBSD.org, jkh@violet.berkeley.edu, toor@jsdinc.root.com Subject: Re: benchmark hell.. Message-ID: <199504260635.QAA08777@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> What is ``DOS''? :-> The correct way is to boot a boot disk for the
>> OS being tested and erase all traces of the previous OS...
^^^
>I guess that could be done, if you trusted the previous OS to not do
>anything to sabatoge performance (for instance, many EIDE drives come
>with boot blocks that have built in INT 13 redirectors for geometry
I don't trust the previous OS. All traces of it on the disk and in
the CMOS must be removed.
>> It takes a fairly special benchmark to demonstrate the speed advantages
>> of delayed context switches.
>I disagree; all it takes is a single process benchmark with a typical
>20 or 30 processes running meanwhile that aren't using FPU.
You mean one process running meanwhile. If there are 20 then the FPU
context will be switched 10 times less often. The FPU context switch
overhead is about 10 usec on a 486/33. If each of the 20 processes runs
for 100 msec, then the FPU context switch overhead is 10 usec every 2
seconds, i.e., a whole 0.0005%. Multiply by 10*10 for a more reasonable
number of runnable processes and a more usual(?) timeslice. Then the
overhead is a whole 0.05%. To demonstrate the speed advantages you
need a special benchmark that forces a context switch after every
few instructions instead of after every 10 msec.
>The microtime requirement is a result of the timer interval being
>equal to the lbolt interval for mandatory context switch. I've argued
>this before.
I've refuted this before :-).
>> copyinstr() is poorly implemented iin FreeBSD. However, I've never seen
>> it showing up in profiling output.
>Then you haven't been looking right. Remember the hoo-rah about the
>speed of a rename? This is part of the problem there. If we consider
I looked again. On a 486DX2/6, copyinstr() takes 4 usec for strings
of length 1 and 66 usec for strings of length 255. rename("a", "b")
takes about 150 usec for a failing rename. rename("a", "b") takes
about 28600 usec for a succeeding rename. (It would of course take
only a few hundred usec on a better file system without immediate
sync of metadata.) A fast copyinstr() is clearly important for that
most important of cases, failing renames of long file names ;-).
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504260635.QAA08777>