Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!super.zippo.com!zdc-e!szdc!news From: "John S. Dyson" <dyson@freebsd.org> 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: Wed, 02 Apr 1997 23:50:35 -0500 Organization: John S. Dyson's home machine Lines: 64 Message-ID: <3343371B.41C67EA6@freebsd.org> References: <331BB7DD.28EC@net5.net> <33402E4E.6937@indy.celebration.net> <5hso11$4ji@fido.asd.sgi.com> <33425A98.167EB0E7@freebsd.org> <5huuso$703@fido.asd.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 3.0-CURRENT i386) Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:38537 comp.unix.bsd.bsdi.misc:6591 comp.sys.sgi.misc:29716 Steve Alexander wrote: > > 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. > I like Larry's idea of showing both the LL syscall overhead and the LL VFS overhead. > > 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. > Some applications consist of numbers of processes using CPU, I/O and have working sets that all have to be serviced, with reasonable overhead. Sometimes there is associated transient paging and/or disk I/O associated with metadata updates (even in read-only applications.) This is the kind of load that a WWW server, FTP server or other internet application box might have. I have some ideas for benchmarks to simulate true loads, but I also am in an advocacy position. It is unlikely, even though I would like to, that I would want to take the responsibility to release a benchmark suite. If I ever quit FreeBSD and become OS neutral, then I might consider doing some, or collaborating with a certain benchmark developer. > > 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. > I agree... I have an anecdote that I find to be very interesting. I found that many of the lmbench results on Unixware weren't too awful far from Linux or FreeBSD (in the same way that Linux and FreeBSD aren't too awful far from each other when running that benchmark suite.) The subjective and loading performance was very very different between FreeBSD and Unixware. Specifically, there were some really strange performance problems when running lat_ctx for example while running on Unixware. I AM NOT flaming Unixware or Lmbench, but I have found little correlation between LL benchmarks in general (either hardware or kernel) and system performance, even under single user multitasking loads. I know that I am (in a way) talking past the issues, and I do understand the need for LL benchmarks... In fact, I enjoy playing benchmark games, but I wish that there was a way to "really" inform the user base as to the meaning of these things (regarding the system wide performance issues.) I want to close and again say that lmbench is a very valuable tool for OS developers, and encourage further development of the package. John