On Tue, 25 Sep 2001, Richard Earnshaw wrote:

> > 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).
[...]
> 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.

As I said above, this is because SetCPSR is used to unblock interrupts, so
you get a lot of things like this (assuming acorn32, which doesn't have
real statclock interrupts):

s = splhigh(); /* or anything that blocks hardclock */
do_stuff();
do_more_stuff();	<--- Hardclock fires here, but it's blocked...
still_doing_stuff();
splx(s); /* which calls... */
 \- SetCPSR();		<--- Interrupts re-enabled, so we handle that hardclock
   \- hardclock();
     \- statclock();	<--- Looks at the irqframe, discovers the IRQ
			     happened in SetCPSR, and charges another
                             clock tick to it.

Thus, SetCPSR() will appear to be responsible for all the CPU time that's
spent with hardclock interrupts disabled.  Does that make sense?

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>