Subject: Re: callgraph ARM7
To: Ben Harris <email@example.com>
From: Richard Earnshaw <firstname.lastname@example.org>
Date: 09/25/2001 13:45:59
> 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.