PowerPC Performance Interrupt

PowerPC Performance Interrupt

[Andrew Fleming]

I think I have a better idea of how oprofile works on ia64 and x86
architectures, now.  In ia64, oprofile grabs the performance monitor
interrupt using request_irq().  In x86, it makes use of the nmi.  I'm
pretty sure that these two solutions are unavailable for PowerPC.  If
I'm wrong, please tell me.

So, it seems to me that in PowerPC, we need to get the
already-installed PerfMon exception handler to call into oprofile.
But, in order to make it so other profiling systems could be used
without further modifying and recompiling the kernel, it seems to me
that there needs to be some way to register to receive the PerfMon
interrupts.

One way would be to have a register function which functions much like
request_irq, but specific to performance monitors.  Functionality could
be provided to lock out others from taking control of the counters,
though there would need to be a way to override the lock (in the event
that the controlling app died).  This would allow oprofile to get
called on interrupt.

Another method would be to register the pid of a control app (perhaps
in /proc), and then have the PerfMon interrupt send a SIG_PROF to
whichever app was registered.  I'm not sure what the consequences are
of there being an interrupt after the monitoring program dies.  Does a
sent signal with a bad destination cause problems?  Anyway, this, too,
should allow oprofile to be informed of the interrupt, though
presumably with higher overhead.

Any thoughts?

Right now, the interrupt is just unhandled.

Andy Fleming


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: PowerPC Performance Interrupt

[John Levon]

On Fri, Mar 14, 2003 at 03:37:20PM -0600, Andrew Fleming wrote:

> So, it seems to me that in PowerPC, we need to get the
> already-installed PerfMon exception handler to call into oprofile.

Well I don't know ppc but this sounds OK

> Another method would be to register the pid of a control app (perhaps
> in /proc), and then have the PerfMon interrupt send a SIG_PROF to
> whichever app was registered.  I'm not sure what the consequences are

This would be very slow, overloads the meaning of SIGPROF, and wouldn't
work anyway with oprofile which needs the post-processing in
drivers/oprofile/buffer_sync.c

regards
john

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/