From owner-freebsd-hackers Wed Apr 26 12:14:39 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA22201 for hackers-outgoing; Wed, 26 Apr 1995 12:14:39 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA22189 for ; Wed, 26 Apr 1995 12:14:34 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA08067; Wed, 26 Apr 95 13:07:45 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504261907.AA08067@cs.weber.edu> Subject: Re: benchmark hell.. To: bde@zeta.org.au (Bruce Evans) Date: Wed, 26 Apr 95 13:07:44 MDT Cc: bde@zeta.org.au, geli.com!rcarter@implode.root.com, hackers@FreeBSD.org, jkh@violet.berkeley.edu, toor@jsdinc.root.com In-Reply-To: <199504260635.QAA08777@godzilla.zeta.org.au> from "Bruce Evans" at Apr 26, 95 04:35:39 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > 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.