> On Tue, 25 Sep 2001, Richard Earnshaw wrote:
> 
> > Secondly, you need to find out where all those calls to SetCPSR are coming
> > from.  SetCPSR is currently defined as ENTRY_NP, though I'm not entirely
> > sure that this is required.
> 
> It is required, because it's used by mcount to protect its internal data
> structures.  See the end of <machine/profile.h>.
> 
> Note that apparently spending a lot of time in SetCPSR may not be
> significant.  Anything which blocks all interrupts will get any statclock
> interrupt queued up and delivered when interrupts are re-enabled, which is
> always in SetCPSR.  You can probably make this better by having real
> statclock interrupts like arm26 does, and perhaps by arranging that
> SetCPSR restore the I flag at the same time as it returns (like
> int_restore does on arm26).
> 
> >  Try building a kernel where it is just a normal ENTRY function.
> 
> This should crash as soon as a profiled function is called.

If all the calls (well most) are comming from within mcount, then you can 
probably ignore SetCPSR as a source of poor performance.  I hadn't 
realized that mcount called it, though it sort of makes sense.  It's still 
a little strange that it is so high up the profile graph, however, given 
that it is such a short function.

R.