porting oprofile to ppc
I'm considering a port to the MPC7400 ("G4") PowerPC. This is out of desperation, since there isn't anything beyond gprof available for Linux/ppc users.
I could use some advice. Where do I even start? Anybody else doing this or interested in helping?
I run both 2.4.xx and 2.5.xx kernels, compiled from source. Neither one has any performance monitoring hooks ready to use. I could add them. What is needed?
I notice that RTC support conflicts with the /dev/rtc driver. Couldn't it use the driver? Sometimes the RTC is available via memory-mapped IO, and sometimes the RTC is emulated by the /dev/rtc driver. Even on x86 you need the /dev/rtc driver to safely set the clock with SMP.
I'm not a Qt fan. Can I avoid it? All my stuff is GNOME, plain X11, or non-GUI. Somehow libqt.so.2.3.1 did get installed though.
On the 7xx and 74xx chips, I get a user-readable 64-bit counter that ticks at 1/16 of the memory bus clock. So on my 450 MHz Mac with a 100 MHz bus, it ticks at 6.25 MHz. There's also a privileged 32-bit count-down register that gives an interrupt. There isn't a CPU core cycle counter, unless you have a 7400 (or above?) and are willing to devote a performance counter to that purpose.
The 7400 chip additionally gives me a set of performance monitoring registers, with read-only access from user code. There are four counters, PMC1 to PMC4, and control registers. I can freeze the counters in kernel mode, in user mode, and according to a flag that may be used to mark a process.
There's a threshold value for some of the performance counters, taking on values from 0..63 times 2 or 32. (0,2,4,...,124,126,128,160,192,...,1952,1984,2016) So for example, I could count loads that stall for more than 1952 ticks.
I can enable counters PMC2..PMC4 when PMC1 goes negative. I can freeze all the counters (or cause an interrupt) when one of PMC2...PMC4 goes negative.
There are ways for external hardware to mask counting or interrupt generation. I'm not about to solder a button onto my CPU for this, but I guess it should be supported.
All four counters can count:
core cycles
completed instructions, excluding folded branches memory cycles divided by 32, 8k, 128k, or 2M instructions dispatched (0, 1, or 2 per core cycle)
Then of course each register has a selection of other choices. Of interest:
instruction breakpoint matches, with a bit mask (could be abused to count system calls or interrupts) various cache things, loads, stores, etc.
There must be 60 to 240 choices, depending on how one counts duplicates.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 3 lines · Albert Cahalan
I run both 2.4.xx and 2.5.xx kernels, compiled from source. Neither one has any performance monitoring hooks ready to use. I could add them. What is needed?
I suggest you start with 2.5 kernels. ppc64 has some oprofile code in the kernel: the first step is to copy that code into ppc32 and make it work. That will give you the basic timer interrupt functionality.
Quoted 2 lines
I notice that RTC support conflicts with the
/dev/rtcdriver. Couldn't it use the driver? Sometimes the RTC
No.
Quoted 3 lines
I'm not a Qt fan. Can I avoid it? All my stuff is GNOME, plain X11, or non-GUI. Somehow libqt.so.2.3.1 did get installed though.
It's completely unnecessary for you to deal with, in any way.
Quoted 5 lines
The 7400 chip additionally gives me a set of performance monitoring registers, with read-only access from user code. There are four counters, PMC1 to PMC4, and control registers. I can freeze the counters in kernel mode, in user mode, and according to a flag that may be used to mark a process.
The crucial thing for perfctr support is that it is able to provide an interrupt when it overflows. Then you (in-kernel) call oprofile_add_sample() to record the EIP etc.
You may need to tweak the certain details of how the perctrs are represented in oprofile userspace, but this is something we can work through. Your first step is to get the ppc64-style support going and working properly.
Hope that helps,
john
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 3 lines · Albert Cahalan
I'm considering a port to the MPC7400 ("G4") PowerPC. This is out of desperation, since there isn't anything beyond gprof available for Linux/ppc users.
Great to hear someone's willing to work on this!
I currently use the following hack to use the pmc's:
I have a trivial kernel module that accepts as parameters the events to count on each pmc (like, insmod pmc.o 1 2 3 4), sets the PMCn and MMCRn regs, and fails to load. This sets the counters running, and then I instrument the program to be profiled to read the PMC's at interesting program locations. I wrote this years ago and never got around to finish any better tools.
Quoted 2 lines
I could use some advice. Where do I even start? Anybody else doing this or interested in helping?
I'll answer any questions you have -- feel free to email me in private about this.
Quoted 2 lines
On the 7xx and 74xx chips, I get a user-readable 64-bit counter that ticks at 1/16 of the memory bus clock. So on
You are talking about the time base? It runs at 1/4th the cpu clock. It can be disabled by means of a hardware pin (GPIO9 on most Mac's); default is running and that's just what you want, I think ;)
Quoted 1 line
my 450 MHz Mac with a 100 MHz bus, it ticks at 6.25 MHz.
25MHz.
Quoted 2 lines
There's also a privileged 32-bit count-down register that gives an interrupt.
The decrementer; same frequency as the time base on all G3 and G4 cpu's.
Quoted 3 lines
There isn't a CPU core cycle counter,
unless you have a 7400 (or above?) and are willing to devote a performance counter to that purpose.
Actually, all G3 and G4 cpu's have event 1 on all pmc's as such a counter.
Quoted 3 lines
The 7400 chip additionally gives me a set of performance monitoring registers, with read-only access from user code. There are four counters, PMC1 to PMC4, and control registers.
750 has four pmc's as well, 7450 has six of-em.
Quoted 2 lines
I can freeze the counters in kernel mode, in user mode, and according to a flag that may be used to mark a process.
There's no mark flag on the 750.
Quoted 9 lines
There's a threshold value for some of the performance counters, taking on values from 0..63 times 2 or 32. (0,2,4,...,124,126,128,160,192,...,1952,1984,2016) So for example, I could count loads that stall for more than 1952 ticks.
I can enable counters PMC2..PMC4 when PMC1 goes negative. I can freeze all the counters (or cause an interrupt) when one of PMC2...PMC4 goes negative.
Or both; the most useful mode, imho.
Quoted 3 lines
There are ways for external hardware to mask counting or interrupt generation. I'm not about to solder a button onto my CPU for this, but I guess it should be supported.
Luckily, GPIO8 is just what you need. It isn't all that useful, though. [Beware: always check the device tree for the exact gpio number on your box -- this can vary].
Quoted 5 lines
All four counters can count:
core cycles
completed instructions, excluding folded branches memory cycles divided by 32, 8k, 128k, or 2M
This one should read "time base ticks".
Quoted 11 lines
instructions dispatched (0, 1, or 2 per core cycle)
Then of course each register has a selection of other choices. Of interest:
instruction breakpoint matches, with a bit mask (could be abused to count system calls or interrupts) various cache things, loads, stores, etc.
There must be 60 to 240 choices, depending on how one counts duplicates.
Lots and lots more combo's, although not all combinations are all that useful ;)
Also, all cpu's have different even assignments (and different MMCRn registers, too).
Good luck and have fun,
Segher
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 7 lines · Segher Boessenkool
Quoted 3 lines · Albert Cahalan
I'm considering a port to the MPC7400 ("G4") PowerPC. This is out of desperation, since there isn't anything beyond gprof available for Linux/ppc users.
Great to hear someone's willing to work on this!
Sort of. "feeling dragged into" is more like it. Porting oprofile looks easier than porting valgrind and kcachegrind, and nobody else seems to care about PowerPC.
Quoted 8 lines
I currently use the following hack to use the pmc's:
I have a trivial kernel module that accepts as parameters the events to count on each pmc (like, insmod pmc.o 1 2 3 4), sets the PMCn and MMCRn regs, and fails to load. This sets the counters running, and then I instrument the program to be profiled to read the PMC's at interesting program locations. I wrote this years ago and never got around to finish any better tools.
Oooh... you shouldn't have said that. I might be mostly satisfied. Right now I'm using a nasty hack involving "gcc -finstrument-functions" and "nm".
I guess I most want instruction pointer (NIP) sampling at irregular intervals, or at least not tied to the clock tick. I could see using some random pre-initialized profiling counter ("42 foo from now") to get this. I could hook into the regular external interrupt and rely on USB traffic to do my sampling. >:-)
Quoted 4 lines
You are talking about the time base? It runs at 1/4th the cpu clock. It can be disabled by means of a hardware pin (GPIO9 on most Mac's); default is running and that's just what you want, I think ;)
Yes. I wonder where I got the 1/16 idea.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 6 lines · Albert Cahalan
Quoted 4 lines
You are talking about the time base? It runs at 1/4th the cpu clock. It can be disabled by means of a hardware pin (GPIO9 on most Mac's); default is running and that's just what you want, I think ;)
Yes. I wonder where I got the 1/16 idea.
Isn't it the bus clock rather ?
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 11 lines · Benjamin Herrenschmidt
Quoted 6 lines · Albert Cahalan
Quoted 4 lines
You are talking about the time base? It runs at 1/4th the cpu clock. It can be disabled by means of a hardware pin (GPIO9 on most Mac's); default is running and that's just what you want, I think ;)
Yes. I wonder where I got the 1/16 idea.
Isn't it the bus clock rather ?
Yes, the cpu bus clock. Sorry about the confusion.
Segher
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
I have been playing around a bit with performance counters on an MPC7441 (eMac), even found an undocumented "issue" with the "retired instructions"
counter: the value is erroneously incremented by interrupts (+1 for each time entering/leaving the interrupt handler), even though it was set up for counting only user-mode instructions. I did these tests via some hijacked system call (vm86), that I adapted to read/write the SPRs. Is no good style, but works for my purposes.
In any case, I would like to offer my help with the porting project. Maybe testing for a beginning, as I need to learn something about kernel modules before being of any help with that...
Regards, Oliver
-----Ursprüngliche Nachricht-----
Von: [email protected] [mailto:[email protected]]Im Auftrag von Albert Cahalan
Gesendet: Samstag, 1. März 2003 00:27
An: [email protected]
Cc: [email protected]
Betreff: porting oprofile to ppc
I'm considering a port to the MPC7400 ("G4") PowerPC. This is out of desperation, since there isn't anything beyond gprof available for Linux/ppc users.
I could use some advice. Where do I even start?
Anybody else doing this or interested in helping?
I run both 2.4.xx and 2.5.xx kernels, compiled from source. Neither one has any performance monitoring hooks ready to use. I could add them. What is needed?
I notice that RTC support conflicts with the /dev/rtc driver. Couldn't it use the driver? Sometimes the RTC is available via memory-mapped IO, and sometimes the RTC is emulated by the /dev/rtc driver. Even on x86 you need the /dev/rtc driver to safely set the clock with SMP.
I'm not a Qt fan. Can I avoid it? All my stuff is GNOME, plain X11, or non-GUI. Somehow libqt.so.2.3.1 did get installed though.
On the 7xx and 74xx chips, I get a user-readable 64-bit counter that ticks at 1/16 of the memory bus clock. So on my 450 MHz Mac with a 100 MHz bus, it ticks at 6.25 MHz. There's also a privileged 32-bit count-down register that gives an interrupt. There isn't a CPU core cycle counter, unless you have a 7400 (or above?) and are willing to devote a performance counter to that purpose.
The 7400 chip additionally gives me a set of performance monitoring registers, with read-only access from user code. There are four counters, PMC1 to PMC4, and control registers. I can freeze the counters in kernel mode, in user mode, and according to a flag that may be used to mark a process.
There's a threshold value for some of the performance counters, taking on values from 0..63 times 2 or 32. (0,2,4,...,124,126,128,160,192,...,1952,1984,2016) So for example, I could count loads that stall for more than 1952 ticks.
I can enable counters PMC2..PMC4 when PMC1 goes negative. I can freeze all the counters (or cause an interrupt) when one of PMC2...PMC4 goes negative.
There are ways for external hardware to mask counting or interrupt generation. I'm not about to solder a button onto my CPU for this, but I guess it should be supported.
All four counters can count:
core cycles
completed instructions, excluding folded branches memory cycles divided by 32, 8k, 128k, or 2M instructions dispatched (0, 1, or 2 per core cycle)
Then of course each register has a selection of other choices. Of interest:
instruction breakpoint matches, with a bit mask (could be abused to count system calls or interrupts) various cache things, loads, stores, etc.
There must be 60 to 240 choices, depending on how one counts duplicates.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/