Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!msunews!news.mtu.edu!newsxfer.itd.umich.edu!newsxfer3.itd.umich.edu!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!ix.netcom.com!enews.sgi.com!fido.asd.sgi.com!refugee.engr.sgi.com!sca From: sca@refugee.engr.sgi.com (Steve Alexander) Newsgroups: comp.unix.bsd.freebsd.misc,comp.unix.bsd.bsdi.misc,comp.sys.sgi.misc Subject: Re: no such thing as a "general user community" Date: 3 Apr 1997 00:50:32 GMT Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 44 Message-ID: <5huuso$703@fido.asd.sgi.com> References: <331BB7DD.28EC@net5.net> <33402E4E.6937@indy.celebration.net> <5hso11$4ji@fido.asd.sgi.com> <33425A98.167EB0E7@freebsd.org> Reply-To: sca@sgi.com NNTP-Posting-Host: fddi-refugee.engr.sgi.com Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:38351 comp.unix.bsd.bsdi.misc:6567 comp.sys.sgi.misc:29641 In article <33425A98.167EB0E7@freebsd.org>, John S. Dyson <dyson@freebsd.org> wrote: >My argument isn't that the measurement isn't relevent, it is that >the LMBENCH suite doesn't always measure what it implies. Additionally, >it requires understanding what it is really doing, and it's limitations >in order to interpret it's results. I think we may now be in violent agreement ;->. None of the issues that you discuss are unique to lmbench, IMO. You should mess around with SPECweb some time. >So, when you say "more representative measure", I am going to ask, >"measure of what?" What Larry & I care about ;->, which is how long it takes to get from user-space into the kernel, through the syscall layer, through the VFS layer, and get something done. That, IMO, is a more useful measure of the OS overhead that I/O-intensive apps are likely see. In my experience, and you can feel free to disagree, apps are divided into two categories: - ones that spend their time doing CPU stuff - ones that spend their time doing I/O Some apps do both. I have seen no apps that I can recall that spend their time doing getpid() or gettimeofday() or things like that (the web server does check the time periodically, but it's not the big-ticket item). So, from my point of view, knowing how long the "null I/O" takes is more important to the types of apps that do I/O. The apps that spend their time doing CPU-intensive tasks don't care about most of the stuff that lmbench reports (they care about context switching and memory latency mostly), and the types of apps that spend their time doing sysconf() don't exist, at least that I've seen. I believe that Larry will have both types of tests in a forthcoming version of lmbench, so then we'll all be satisfied ;-> It's certainly the case that optimizing the basic syscall path is important, but we should not believe that it's the only thing we need to fix to get lower I/O overhead. -- Steve Alexander | Silicon Graphics, Inc. | +1 (415) 933-6172 (Voice) sca@sgi.com | http://reality.sgi.com/sca | +1 (415) 933-0513 (FAX) "I'm going outside and I'm gonna learn Perl."