Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!news.bbnplanet.com!cpk-news-hub1.bbnplanet.com!worldnet.att.net!news.mathworks.com!news.kei.com!news.texas.net!news1.best.com!nntp1.best.com!not-for-mail
From: dillon@flea.best.net (Matt Dillon)
Newsgroups: comp.unix.bsd.freebsd.misc,comp.arch,comp.benchmarks
Subject: Re: benchmarking discussion at Usenix?
Date: 15 Jan 1997 16:34:03 -0800
Organization: BEST Internet Communications, Inc.
Lines: 49
Message-ID: <5bjt1r$5rg@flea.best.net>
References: <5am7vo$gvk@fido.asd.sgi.com> <32D18190.369A6C81@informatik.tu-muenchen.de> <5av0jb$aus@uriah.heep.sax.de> <32DAD3AF.15FB@nas.nasa.gov>
NNTP-Posting-Host: flea.best.net
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:34094 comp.arch:62444 comp.benchmarks:18900
:In article <32DAD3AF.15FB@nas.nasa.gov>,
:Hugh LaMaster <lamaster@nas.nasa.gov> wrote:
:>J Wunsch wrote:
:>
:>> Bernd Paysan <paysan@informatik.tu-muenchen.de> wrote:
:>
:>> > > Only curious: what are the goals for this?
:>
:>> > OS code has somewhat different characteristic from user code. If you
:>
:>> That's been my basic question, yes. I wasn't aware that the typical
:>> usage pattern of kernel code differs that much from user code.
:>
:>Many "user code" benchmarks run with almost zero cache hits if
:>the cache is large enough. But, the work I was referring to
:>has shown substantially higher actual cache miss rates on kernel
:>code vs user code. It depends on what you consider "user code",
:>though - apparently some RDBMS's and some bulky C++ codes are now
:>as bad or worse than kernel code used to be for the same footprint
:>comparisons. If we are looking at the more well-behaved and compact
:>"user code" benchmarks of yesteryear, then kernel code looks worse.
:>[Supposedly. I don't have the citations handy.]
:>
:>
:>> > Another part is exception and interrupt handling.
:>
:>> Hmm. This can't be expressed in a benchmark, hardly. OTOH, if the
:>> system keeps reasonable statistics, the effect of interrupt and
:>> exception handling should be forseeable. I estimate this being less
:>> than ~ 10 % of the total time on a modern machine.
:>
:>I guess it depends on whether or not you have to drive
:>dumb ugly serial ports and such like. You can spend
:>a lot of time handling interrupts with such devices.
:>One paper at Usenix showed Linux on a Pentium dropping
:>interrupts/data when driving a 115 Kbps serial port...
The ISA bus cycles used to access the serial ports (in most cases)
are slow, but not THAT slow. Any problem linux has with serial
data overruns is readily attributable to long interrupt disables
in other parts of the kernel and the fact that the PC-standard
serial chipset is braindead when it comes to on-chip hardware
handshaking. It has nothing to do with the processing
time required to handle the serial interrupt.
PC serial ports are the exception rather then the rule.
-Matt