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>