Subject: Re: q_to_b() question
To: Chris G. Demetriou <cgd@sibyte.com>
From: Robert Elz <kre@munnari.OZ.AU>
List: tech-kern
Date: 09/21/2000 03:50:56
Date: 20 Sep 2000 08:40:38 -0700
From: cgd@sibyte.com (Chris G. Demetriou)
Message-ID: <5thf7bax6x.fsf@highland.sibyte.com>
| Anyway, the point is: "sense" in this case shouldn't be initially
| determined by a few voices on this mailing list. Rather it should be
| first determined by performance measurement and analysis.
This is a good point, and one I had been wondering about. Back in the
"old days" there used to be lots of kernel profiling going on, no-one
would think of doing anything whose purpose was to supposedly improve
performance without doing before/during/after profiling to determine if
improvement was actually needed (it doesn't matter how awful the code
performance is, if it only runs once a month in an otherwise idle period)
and then whether the "improved" (and typically more complex) code actually
delivers a benefit worth having.
There doesn't seem to be a lot of kernel profiling being done under NetBSD
(or is it all just being kept private)? From time to time there are messages
that make it clear that user level timimg tests are being done occasionally
(how long it takes to compile the kernel, etc) but I don't see anything much
about kernel profiling.
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)?
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 ??
kre