Simon Burge wrote:
> 
> I should add almost nothing to the kernel - MCOUNT_ENTRY and MCOUNT_EXIT
> are only in __mcount.  I don't have any hard data on the performance
> impact, but it saves a function call...
> 
	You're right -- never mind!

> The first thing that springs to mind is what if a function is called
> frequenctly, but is never active during the clock interrupt?  I'd
> be curious to see comparisons of the call graphs between the two
> implementations.
> 
	It seems unlikely that it would pathologically avoid clock ticks, but
not inconceivable. However we're already screwed in that event, since we
only mark time off in a function in each clock tick. ie. the time
in-function is already wrong in that case. It's only the call-graph that
is affected. Also, the call graphs are going to be significantly
different as part of the design.

> Also, isn't MIPS stack unwinding inherent unreliable?  Certainly seems
> so in userland (fencepost errors and such from gdb) - it the kernel a
> little more well behaved in this respect?
> 
	This seems a reasonable concern. We'll be able to backtrace as well as
"trace" can within ddb. I think that it's pretty reliable for the trace,
although not the arguments to functions. It can't backtrace behind a few
of the trap/interrupt/etc entry functions, but I think that that should
be fine.

	It could always be implemented as an option, not as a replacement. But
I'm also trying to discern whether anyone cares to have the call-graph
be based on time, rather than function-calls. If no one cares, then it's
probably not worth the time to discuss it. 8-)
	-- Ethan