On Thu, Jan 27, 2005 at 11:17:17AM -0700, Jesse Off wrote:
> I'm not entirely certain that its splx() itself thats slow code.  It may be 
> being accounted for more time because its getting some portion of the intr 
> handler preamble. (?)  Or perhaps its getting more time because of IRQ 
> return/entry processor overhead and the inevitable L1 cache refills when a 
> intr is returned from?  I think I need to learn more on how profiling 
> timing is internally implemented and accounted for.  I could always make 
> spl*() hand asm, but I'm not sure if hand optimized ASM is going to be any 
> better than what GCC is already emitting for these very simple functions.

what's happening is that all of the time spent excuting the code between
the splfoo() and the splx() is reported as being used by splx(), since splx()
is what's excuting when the profiling interrupt is actually processed.
the way to get better info is to turn splx() into an inline function
(at least while profiling), so that the interrupt is recorded as happening
in the middle of the caller of splx() instead.

if you can adjust interrupt priorities so that the profiling clock interrupt
is at a higher priority, that helps too.

-Chuck