I now have kernel profiling working on our MIPS platform, with the
increase in stack size for mcount and Simon's noprof spl functions. (I
haven't tried the inline assembler code -- what does that do to the size
of the kernel?) However, I'm used to a different implementation, and I
wanted to gather opinions.

	The way it works today, the actual time spent within a function is
accurate, since that's recorded from a clock interrupt. But the call
graph information is generated per function call, so it isn't based upon
time but on number-of-calls.

	simplified eg: write() always takes twice as long as read(), let's say.
If they're both called equally often by a given function, then they'll
be listed (in the gprof output for that function) with equal weightings.
But the writes actually took twice as long as the reads. If you're using
the profiling to see what is actually happening in terms of code flow,
then this is what you want. If you're looking for performance
bottlenecks, this is useless.

	What I'm used to is having the clock interrupt perform a backtrace in
the interrupt routine, and fill in the call-graph information at clock
interrupt time. In return, you do *not* need a profiled kernel. No
mcount function. No performance hit on every function call. No separate
kernels for profiling and regular use.

	And, for the example given above, you'd see your function as spending
twice as much time in write() as in read(). In fact, you'll actually see
exact times you spent in your child functions, rather than the
number-of-function-calls number.

	I don't want to claim that this is superior to the current
implementation, since they both have uses. I'm mostly seeking people's
opinions about the desirability of this alternate implementation.
	-- Ethan