Greg, 

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?

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 noticed that gcc generates a little better code from the shift
implementations in libgcc2 compared with our code in libkern.  A brief
look leads me to believe an assembly hacker could probably shave some
cycles there too.

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

	--jtc