Subject: Re: Performance dive
To: Jeffrey M. Smith <jeffs@atheros.com>
From: Chuck Silvers <chuq@chuq.com>
List: port-pmax
Date: 03/19/2001 08:44:28
the issue was that it bugged me to have "_splset_noprof" showing up
as a high-runner in the profiling output, and it wasn't obvious where
this was coming from.  but looking at it a bit more, this function is
only called from __mcount(), so it can be counted entirely as
profiling overhead.

I rather like what the sparc does, implementing all of the spl stuff
as inline C functions with asm()s to get at the special registers
rather than entirely in assembly.  we might not want to inline spl*()
in production kernels, but having the ability to make them inline
everywhere for profiling would enable us to see which functions
which block interrupts actually hold them blocked for a longer
period of time, since then the time with interrupts blocked would
show up in the caller of spl*() rather than in _splset().

so I guess I don't want to just undo this anymore, but something
a bit fancier.  I'll chew on this some more.

-Chuck


On Sun, Mar 18, 2001 at 07:16:06PM -0800, Jeffrey M. Smith wrote:
> Simon Burge wrote:
> > I originally was going to use noprofiled spl routines for profile.h but
> > switched to inline blocking of interrupts for reasons I can't remember
> > anymore.  Jeff (well, Geocast) were using noprofiled spl routines and at
> > the time we didn't see any differences with in-practice use (ie, icache
> > misses vs. function call overhead) so we switched to better align our
> > code with Geocast's.  If indeed this change has made things worse, then
> > I don't have any problems with it being backed out.  Jeff?
> 
> I didn't like the inline code as the Geocast (RIP) machine had
> special handling of the SR, and my goal was to keep that messy
> code in as few places as possible.  Looking at the code now,
> that's probably ok as it appears to only flip SR_IE.
> 
> Is the issue that the tools pick-up spl*_noprof instead
> of spl*?  Or that results turned up there instead of
> mcount?
> 
> Could this be improved by moving the code out of the XLEAF
> into is's own LEAF named as spl*_mcount?
> 
> Or am I missing something else (it's very likely as I've
> been working on other stuff for a while)?
> 
> jeffs