Subject: Re: seemingly dismal performance of NetBSD-1.1A/sun3 file I/O....
To: J.T. Conklin <jtc@cygnus.com>
From: Greg A. Woods <woods@most.weird.com>
List: current-users
Date: 04/11/1996 00:18:01
[ On Wed, April 10, 1996 at 13:08:17 (-0700), J. T. Conklin wrote: ]
> Subject: Re: seemingly dismal performance of NetBSD-1.1A/sun3 file I/O.... 
>
> I'm not familar with the benchmarks you are using.  Do they measure
> filesystem or raw disk performance?  Are operations "large" enough
> to eliminate bias from SunOS' vm/buffer cache?

They're fairly well known filesystem benchmarks.  They do try to
explicitly avoid the influence of the buffer cache.  Iozone by default
writes up to a 16 MB file, and Bonnie uses a 100 MB file or more.
Bonnie was done by Tim Bray in conjunction with the New OED project, and
iozone has been a comp.sources.misc tool from way back.

I've put copies of them in ftp://ftp.weird.com/pub for reference...

> Someone mentioned the possibility of the performance problem resulting
> from cpu bound operations.  That got be to thinking about whether the
> 64 bit filesystem offsets has anything to do with it?  Gcc does not
> open code 64 bit shifts or division on the m68k, and shifts seem to
> occur rather frequently in the filesystem code.

I've been assuming the 64-bit operations only happen when the file
metadata is being manipulated, which shouldn't be all that often if
you're only working with a single file, no?

It would be good to do a cycle count in the code path that updates the
inode access times though....  Since this code is executed with every
file manipulation call, it would indeed be best to have it use as few
cycles as possible.

Maybe I'll try some compiler benchmarks with some representative code.
Actually, the standard SPECmark tests on identical hardware might be a
good comparison, as in many respects these are really just compiler
benchmarks (with a wee bit of system stuff thrown in for good measure).
Anybody know where I can find the code for them, or do I have to stoop
to using the Byte benchmarks?

> Of course, doing so makes little sense unless the shifts contribute
> significantly to the cpu load.  What tools are available to profile
> the kernel?

I've not found any yet.  I'd know what to do with tools similar to the
kernel profiling support in UNIX SysVr3.2....

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>