Subject: Re: q_to_b() question
To: Robert Elz <kre@munnari.OZ.AU>
From: Chris G. Demetriou <cgd@sibyte.com>
List: tech-kern
Date: 09/20/2000 11:06:24
Robert Elz <kre@munnari.OZ.AU> writes:
> There doesn't seem to be a lot of kernel profiling being done under NetBSD
> (or is it all just being kept private)?

I believe that some people occasionally do some, but I believe that
the correct first order approximation is probably "almost none."  8-)


> Do the kernel profiler and tools all work properly on NetBSD (I'm not
> currently doing any kernel work, so I haven't had the incentive to
> investigate)?

By and large, yes.  Not an unqualified yes because sometimes they stop
working because of changes, etc., and i don't know that the default
state on all architectures is "working."


> Maybe it would be a good idea to specify a few fairly simple, but
> realistic, user loads that could be run under kernel profiling, (like
> compiling the kernel, or starting kde, or a bonnie run, or
> find /usr/src -print | xargs wc -l >/dev/null ) that would be fairly
> easy to reproduce anywhere - and the kernel profile data for that
> for the various ports posted on the NetBSD web site - so it would be
> fairly easy for everyone to see where useful kernel performance work
> might be done ??

This would almost certainly be a good idea.

Actually, I'd think that something like this could be a small side
effect of a useful testing strategy, which NetBSD needs.  Timing some
of those simple, easily reproducable tests should be considered part
of adequately testing the system, and once you're doing that it'd be
easy to do another run with kernel profiling turned on.

(If you ever have to say "hey, look, starting the window system just
got 20% slower, wonder what happened there..." some would argue that's
a serious bug... and smaller percentages are probably worth taking
issue with, too.  Of course, with the more complex bits of software,
it's hard to cope with performance changes with new versions, but that
can be solved.)


cgd