Date: Wed, 26 Apr 95 13:07:44 MDT From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, geli.com!rcarter@implode.root.com, hackers@FreeBSD.org, jkh@violet.berkeley.edu, toor@jsdinc.root.com Subject: Re: benchmark hell.. Message-ID: <9504261907.AA08067@cs.weber.edu> In-Reply-To: <199504260635.QAA08777@godzilla.zeta.org.au> from "Bruce Evans" at Apr 26, 95 04:35:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
This assumes full quantum use before switch; this is actually quite
atypical, and a context switch is much more likely the result of a
voluntary switch coming from an attempt at a blocking operation. 8-).
> >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 :-).
Yet that microtime() is still there. 8-(.
> >> 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 ;-).
The total duration of a file system related system call that isn't a
read or write on UnixWare is 20uS. FreeBSD ought to be able to compete.
At 4uS, this is 20% of the overhead.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504261907.AA08067>