From: Beaman, T. <Tho...@xe...> - 2016-07-06 15:01:08
|
When I am running on my PPC E5500 system oprofile cannot detect the CPU operf --version Unable to obtain cpu_type Looking at op_cpu_type.h I see entries for CPU_PPC_E500MC, /**< e500mc */ CPU_PPC_E6500, /**< e6500 */ But no entry for the PPC E5500. The E5500 is very similar to e500mc and the E6500. Can support be added for this processor ? Thanks, Tom |
From: William C. <wc...@re...> - 2016-07-07 14:33:34
|
On 07/06/2016 10:26 AM, Beaman, Thomas wrote: > When I am running on my PPC E5500 system oprofile cannot detect the CPU > > > > operf --version > > Unable to obtain cpu_type > > > > Looking at op_cpu_type.h I see entries for > > > > CPU_PPC_E500MC, /**< e500mc */ > > CPU_PPC_E6500, /**< e6500 */ > > > > But no entry for the PPC E5500. The E5500 is very similar to e500mc and the E6500. Can support be added for this processor ? > > > > Thanks, > > Tom Hi Tom, It is not difficult to add support for additional processors to oprofile. The main question is does the kernel being used on the system support access to the PPC E5500 performance monitoring hardware. OProfile now uses the linux perf infrastructure in the kernel. If that is available on the machine the command "perf list" should list out the available events and include some that are hardware events. For the older method that is no longer supported in the current version of oprofile the kernel provided a oprofile kernel module. The kernel module provided information about what type of processor the machine was. To add support for a new process there will need to be some additions in oprofile libop files to identify the processor type. descriptions of the events in events/ppc for the processor. The events might be similar to other existing processors and you might be able to map the processor to an existing set of events, but there can be differences that require separate set of files describing the events. -Will |
From: Beaman, T. <Tho...@xe...> - 2016-07-07 17:49:02
|
-----Original Message----- From: William Cohen [mailto:wc...@re...] Sent: Thursday, July 07, 2016 10:33 AM To: Beaman, Thomas; opr...@li... Subject: Re: oprofile support for PPC_E5500 On 07/06/2016 10:26 AM, Beaman, Thomas wrote: > When I am running on my PPC E5500 system oprofile cannot detect the CPU > > > > operf --version > > Unable to obtain cpu_type > > > > Looking at op_cpu_type.h I see entries for > > > > CPU_PPC_E500MC, /**< e500mc */ > > CPU_PPC_E6500, /**< e6500 */ > > > > But no entry for the PPC E5500. The E5500 is very similar to e500mc and the E6500. Can support be added for this processor ? > > > > Thanks, > > Tom Hi Tom, It is not difficult to add support for additional processors to oprofile. The main question is does the kernel being used on the system support access to the PPC E5500 performance monitoring hardware. OProfile now uses the linux perf infrastructure in the kernel. If that is available on the machine the command "perf list" should list out the available events and include some that are hardware events. For the older method that is no longer supported in the current version of oprofile the kernel provided a oprofile kernel module. The kernel module provided information about what type of processor the machine was. To add support for a new process there will need to be some additions in oprofile libop files to identify the processor type. descriptions of the events in events/ppc for the processor. The events might be similar to other existing processors and you might be able to map the processor to an existing set of events, but there can be differences that require separate set of files describing the events. -Will >>>>>>>>>>>>>>>>> Hi Will, The kernel I have does support a current version of OProfile. I have OProfile 1.1.0 running on a 4.1 kernel on a different CPU (X86_64). I have checked and perf does list the following hardware events for the ppc E5500 target. branch-instructions OR branches [Hardware event] branch-misses [Hardware event] cache-misses [Hardware event] cpu-cycles OR cycles [Hardware event] instructions [Hardware event] stalled-cycles-backend OR idle-cycles-backend [Hardware event] stalled-cycles-frontend OR idle-cycles-frontend [Hardware event] Michael Petlan has also replied with a patch for the ppc-e5500 that I will try. Thanks for your quick reply, let me know if there is any other info I can supply. Tom |
From: Michael P. <mp...@re...> - 2016-07-07 14:47:50
Attachments:
ppc-e5500.patch
check_events.sh
|
Hi, could you please test the attached patch? E6500 also has the same PMU events as E500mc plus some more. It would be good to know what the set of events supported by the E5500 actually is. Please run the oprofile-tests testsuite and the attached test and send the logs from the second one? Anyway, it would be nice if someone more appropriate reviewed the events and checks the kernel support, etc. Thanks. Michael On Wed, 6 Jul 2016, Beaman, Thomas wrote: > When I am running on my PPC E5500 system oprofile cannot detect the CPU > > > > operf --version > > Unable to obtain cpu_type > > > > Looking at op_cpu_type.h I see entries for > > > > CPU_PPC_E500MC, /**< e500mc */ > > CPU_PPC_E6500, /**< e6500 */ > > > > But no entry for the PPC E5500. The E5500 is very similar to e500mc and the E6500. Can support be added for this processor ? > > > > Thanks, > > Tom > > > > > > > |
From: Michael P. <mp...@re...> - 2016-07-08 17:16:08
|
On Fri, 8 Jul 2016, Beaman, Thomas wrote: > Hi Michael, > Hi Tom, > I wanted to update you on my status. I was able to apply your patch, but I did notice a few recommendations for change. > > The E5500 is a 64 bit cpu like the E6500. I have noticed that the E6500 has entries in both the ppc and ppc64 directories. Also the op_cpu_type.c file has two entries ppc/e6500 and ppc64/e6500. I believe the e5500 should also be like this. I don't see any ppc64/e6500 dir. Do you have the same git tree? https://sourceforge.net/p/oprofile/oprofile/ci/master/tree/events/ppc64/ [Michael@Diego oprofile]$ ls events/ppc64 events/ppc events/ppc: 7450 e300 e500 e500mc e500v2 e5500 e6500 events/ppc64: 970 970MP architected_events_v1 power4 power5 power5+ power5++ power6 power7 power8 The same with op_cpu_type.c: [Michael@Diego oprofile]$ grep -P -i ppc6?4?/e6500 ./libop/op_cpu_type.c { "e6500", "ppc/e6500", CPU_PPC_E6500, 6 }, Anyway, it should not matter whether the events/unit_masks files are in ppc or ppc64 dir, as you can see, Intel datafiles are in i386 dir while AMD files are in x86-64, no matter that Intel CPUs run in 64bit mode now. Regarding to the ppc/ppc64, you can see that ppc64 dir contains IBM POWER processors, while ppc is for the others. > > After applying your patch I made the following changes by hand. > > Add ppc64/e5500 event and unit_masks (with includes pointing to ppc64/e6500) > Add ppc64/e5500 entry to op_cpu_type.c > Fix typo in ppc/unit_masks include:ppc/6500 should be include:ppc/e6500 Yes, I haven't noticed the typo. Thanks. > > After these changes I am now able to run ophelp and it list lots of info, so it is now detecting the cpu. The command `ophelp -r` should print the processor type If ophelp is reporting events, it is good news. > > I tried running your check_events.sh script but was running into problems. I am off until Monday but I wanted to give you a status update. If you want to modify the patch I can test a new one on Monday and also figure out what is going on with check_events. The script just parses all the supported events from ophelp and then it runs `ocount -b -e $event -- sleep 0.2` against each of them. There's no E5500 or any other similar CPU available for me, just an IBM POWER7 box and I have no problems running the script there. You may try it manually: perl -ne 'print "$1\n" if /name:(\w+)\s/' < events/ppc/e6500/events > events.list for i in `cat events.list`; do ocount -b -e $i -- sleep 0.2 >> result.log done > > I do not know the posting protocol, should I be posting this reply to the oprofile-list or is direct communications acceptable ? If it should go to the list can you forward it on and let me know for future postings. It's always better when the messages go to the list, since other people might find them useful later on. > > Thanks for your help so far, > Tom Michael > > > > > -----Original Message----- > From: Michael Petlan [mailto:mp...@re...] > Sent: Thursday, July 07, 2016 10:48 AM > To: Beaman, Thomas > Cc: opr...@li... > Subject: Re: oprofile support for PPC_E5500 > > Hi, > > could you please test the attached patch? > > E6500 also has the same PMU events as E500mc plus some more. > It would be good to know what the set of events supported by the E5500 actually is. > > Please run the oprofile-tests testsuite and the attached test and send the logs from the second one? > > Anyway, it would be nice if someone more appropriate reviewed the events and checks the kernel support, etc. > > Thanks. > Michael > > > On Wed, 6 Jul 2016, Beaman, Thomas wrote: >> When I am running on my PPC E5500 system oprofile cannot detect the >> CPU >> >> >> >> operf --version >> >> Unable to obtain cpu_type >> >> >> >> Looking at op_cpu_type.h I see entries for >> >> >> >> CPU_PPC_E500MC, /**< e500mc */ >> >> CPU_PPC_E6500, /**< e6500 */ >> >> >> >> But no entry for the PPC E5500. The E5500 is very similar to e500mc and the E6500. Can support be added for this processor ? >> >> >> >> Thanks, >> >> Tom >> >> >> >> >> >> >> > |
From: Beaman, T. <Tho...@xe...> - 2016-07-11 19:11:06
|
> -----Original Message----- > From: Michael Petlan [mailto:mp...@re...] > Sent: Friday, July 08, 2016 1:16 PM > To: Beaman, Thomas > Cc: Michael Petlan; William Cohen; opr...@li... > Subject: RE: oprofile support for PPC_E5500 > > On Fri, 8 Jul 2016, Beaman, Thomas wrote: > > Hi Michael, > > > > Hi Tom, > > > I wanted to update you on my status. I was able to apply your patch, but I > did notice a few recommendations for change. > > > > The E5500 is a 64 bit cpu like the E6500. I have noticed that the E6500 has > entries in both the ppc and ppc64 directories. Also the op_cpu_type.c file > has two entries ppc/e6500 and ppc64/e6500. I believe the e5500 should also > be like this. > > I don't see any ppc64/e6500 dir. Do you have the same git tree? > https://sourceforge.net/p/oprofile/oprofile/ci/master/tree/events/ppc64/ I did some looking into this, and I have oprofile version 1.1.0 but my linux vendor (WindRiver linux) does add a patch called oprofile-wr-add-ppc64-e6500-support.patch which adds entries to the ppc64 event dir and updates the op_cpu_type.c file with a ppc64/e6500 entry. (very similar type of updates as your patch) > > [Michael@Diego oprofile]$ ls events/ppc64 events/ppc > events/ppc: > 7450 e300 e500 e500mc e500v2 e5500 e6500 > events/ppc64: > 970 970MP architected_events_v1 power4 power5 power5+ power5++ > power6 power7 power8 > > The same with op_cpu_type.c: > > [Michael@Diego oprofile]$ grep -P -i ppc6?4?/e6500 ./libop/op_cpu_type.c > { "e6500", "ppc/e6500", CPU_PPC_E6500, 6 }, > > Anyway, it should not matter whether the events/unit_masks files are in ppc > or ppc64 dir, as you can see, Intel datafiles are in i386 dir while AMD files are > in x86-64, no matter that Intel CPUs run in 64bit mode now. Regarding to the > ppc/ppc64, you can see that ppc64 dir contains IBM POWER processors, while > ppc is for the others. > What you say is probably correct for intel, but from actual testing this does not appear to be the case for PowerPC. If I do not have the ppc64/e5500 entries the cpu is NOT detected. This is probably why Windriver has added the ppc64/e6500 patch. > > > > After applying your patch I made the following changes by hand. > > > > Add ppc64/e5500 event and unit_masks (with includes pointing to > > ppc64/e6500) Add ppc64/e5500 entry to op_cpu_type.c Fix typo in > > ppc/unit_masks include:ppc/6500 should be include:ppc/e6500 > Yes, I haven't noticed the typo. Thanks. > > > > > After these changes I am now able to run ophelp and it list lots of info, so it > is now detecting the cpu. > > The command `ophelp -r` should print the processor type If ophelp is > reporting events, it is good news. > root@miopqt_250:~# ophelp -r e5500 but I can only get this if I have ppc64/e5500 entries in op_cpu_type.c and the ppc64/e5500 directory. > > > > I tried running your check_events.sh script but was running into problems. > I am off until Monday but I wanted to give you a status update. If you want > to modify the patch I can test a new one on Monday and also figure out what > is going on with check_events. > > The script just parses all the supported events from ophelp and then it runs > `ocount -b -e $event -- sleep 0.2` against each of them. > > There's no E5500 or any other similar CPU available for me, just an IBM > POWER7 box and I have no problems running the script there. > > You may try it manually: > > perl -ne 'print "$1\n" if /name:(\w+)\s/' < events/ppc/e6500/events > > events.list for i in `cat events.list`; do > ocount -b -e $i -- sleep 0.2 >> result.log done > The problem with the script is my system would not accept sleep 0.2. I have changed it to sleep 1 and now it is working. I have attached the output files events.list, results.log and supported.list > > > > I do not know the posting protocol, should I be posting this reply to the > oprofile-list or is direct communications acceptable ? If it should go to the list > can you forward it on and let me know for future postings. > > It's always better when the messages go to the list, since other people might > find them useful later on. > > > > > Thanks for your help so far, > > Tom > > Michael > > > > > > > > > > > -----Original Message----- > > From: Michael Petlan [mailto:mp...@re...] > > Sent: Thursday, July 07, 2016 10:48 AM > > To: Beaman, Thomas > > Cc: opr...@li... > > Subject: Re: oprofile support for PPC_E5500 > > > > Hi, > > > > could you please test the attached patch? > > > > E6500 also has the same PMU events as E500mc plus some more. > > It would be good to know what the set of events supported by the E5500 > actually is. > > > > Please run the oprofile-tests testsuite and the attached test and send the > logs from the second one? > > > > Anyway, it would be nice if someone more appropriate reviewed the > events and checks the kernel support, etc. > > > > Thanks. > > Michael > > > > > > On Wed, 6 Jul 2016, Beaman, Thomas wrote: > >> When I am running on my PPC E5500 system oprofile cannot detect the > >> CPU > >> > >> > >> > >> operf --version > >> > >> Unable to obtain cpu_type > >> > >> > >> > >> Looking at op_cpu_type.h I see entries for > >> > >> > >> > >> CPU_PPC_E500MC, /**< e500mc */ > >> > >> CPU_PPC_E6500, /**< e6500 */ > >> > >> > >> > >> But no entry for the PPC E5500. The E5500 is very similar to e500mc and > the E6500. Can support be added for this processor ? > >> > >> > >> > >> Thanks, > >> > >> Tom > >> > >> > >> > >> > >> > >> > >> > > |
From: William C. <wc...@re...> - 2016-07-11 19:49:23
|
On 07/11/2016 02:36 PM, Beaman, Thomas wrote: > >> -----Original Message----- >> From: Michael Petlan [mailto:mp...@re...] >> Sent: Friday, July 08, 2016 1:16 PM >> To: Beaman, Thomas >> Cc: Michael Petlan; William Cohen; opr...@li... >> Subject: RE: oprofile support for PPC_E5500 >> >> On Fri, 8 Jul 2016, Beaman, Thomas wrote: >>> Hi Michael, >>> >> >> Hi Tom, >> >>> I wanted to update you on my status. I was able to apply your patch, but I >> did notice a few recommendations for change. >>> >>> The E5500 is a 64 bit cpu like the E6500. I have noticed that the E6500 has >> entries in both the ppc and ppc64 directories. Also the op_cpu_type.c file >> has two entries ppc/e6500 and ppc64/e6500. I believe the e5500 should also >> be like this. >> >> I don't see any ppc64/e6500 dir. Do you have the same git tree? >> https://sourceforge.net/p/oprofile/oprofile/ci/master/tree/events/ppc64/ > > I did some looking into this, and I have oprofile version 1.1.0 but my linux vendor (WindRiver linux) does add a patch called > > oprofile-wr-add-ppc64-e6500-support.patch > > which adds entries to the ppc64 event dir and updates the op_cpu_type.c file with a ppc64/e6500 entry. (very similar type of updates as your patch) Hi Thomas, Would it be possible to have someone from Wind River submit the e6500 patch for review? It would be nice to eliminate the need for this patch for the next oprofile release. It does look like the pmu control hardware is pretty similar for e500, e5500, and e6500: http://cache.freescale.com/files/32bit/doc/ref_manual/EREF_RM.pdf. However, the actual performance events supported for the e500 and e6500 differ. It is likely there are event differences between e5500 and e6500 so simply including e6500 for e5500 is likely to have some incorrect entries. However, I haven't found a list of events for the e5500 around. -Will > >> >> [Michael@Diego oprofile]$ ls events/ppc64 events/ppc >> events/ppc: >> 7450 e300 e500 e500mc e500v2 e5500 e6500 >> events/ppc64: >> 970 970MP architected_events_v1 power4 power5 power5+ power5++ >> power6 power7 power8 >> >> The same with op_cpu_type.c: >> >> [Michael@Diego oprofile]$ grep -P -i ppc6?4?/e6500 ./libop/op_cpu_type.c >> { "e6500", "ppc/e6500", CPU_PPC_E6500, 6 }, >> >> Anyway, it should not matter whether the events/unit_masks files are in ppc >> or ppc64 dir, as you can see, Intel datafiles are in i386 dir while AMD files are >> in x86-64, no matter that Intel CPUs run in 64bit mode now. Regarding to the >> ppc/ppc64, you can see that ppc64 dir contains IBM POWER processors, while >> ppc is for the others. >> > > What you say is probably correct for intel, but from actual testing this does not appear to be the case for PowerPC. If I do not have the ppc64/e5500 entries the cpu is NOT detected. This is probably why Windriver has added the ppc64/e6500 patch. > > >>> >>> After applying your patch I made the following changes by hand. >>> >>> Add ppc64/e5500 event and unit_masks (with includes pointing to >>> ppc64/e6500) Add ppc64/e5500 entry to op_cpu_type.c Fix typo in >>> ppc/unit_masks include:ppc/6500 should be include:ppc/e6500 >> Yes, I haven't noticed the typo. Thanks. >> >>> >>> After these changes I am now able to run ophelp and it list lots of info, so it >> is now detecting the cpu. >> >> The command `ophelp -r` should print the processor type If ophelp is >> reporting events, it is good news. >> > > root@miopqt_250:~# ophelp -r > e5500 > > but I can only get this if I have ppc64/e5500 entries in op_cpu_type.c and the ppc64/e5500 directory. > > >>> >>> I tried running your check_events.sh script but was running into problems. >> I am off until Monday but I wanted to give you a status update. If you want >> to modify the patch I can test a new one on Monday and also figure out what >> is going on with check_events. >> >> The script just parses all the supported events from ophelp and then it runs >> `ocount -b -e $event -- sleep 0.2` against each of them. >> >> There's no E5500 or any other similar CPU available for me, just an IBM >> POWER7 box and I have no problems running the script there. >> >> You may try it manually: >> >> perl -ne 'print "$1\n" if /name:(\w+)\s/' < events/ppc/e6500/events > >> events.list for i in `cat events.list`; do >> ocount -b -e $i -- sleep 0.2 >> result.log done >> > > The problem with the script is my system would not accept sleep 0.2. I have changed it to sleep 1 and now it is working. I have attached the output files events.list, results.log and supported.list > >>> >>> I do not know the posting protocol, should I be posting this reply to the >> oprofile-list or is direct communications acceptable ? If it should go to the list >> can you forward it on and let me know for future postings. >> >> It's always better when the messages go to the list, since other people might >> find them useful later on. >> >>> >>> Thanks for your help so far, >>> Tom >> >> Michael >> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Michael Petlan [mailto:mp...@re...] >>> Sent: Thursday, July 07, 2016 10:48 AM >>> To: Beaman, Thomas >>> Cc: opr...@li... >>> Subject: Re: oprofile support for PPC_E5500 >>> >>> Hi, >>> >>> could you please test the attached patch? >>> >>> E6500 also has the same PMU events as E500mc plus some more. >>> It would be good to know what the set of events supported by the E5500 >> actually is. >>> >>> Please run the oprofile-tests testsuite and the attached test and send the >> logs from the second one? >>> >>> Anyway, it would be nice if someone more appropriate reviewed the >> events and checks the kernel support, etc. >>> >>> Thanks. >>> Michael >>> >>> >>> On Wed, 6 Jul 2016, Beaman, Thomas wrote: >>>> When I am running on my PPC E5500 system oprofile cannot detect the >>>> CPU >>>> >>>> >>>> >>>> operf --version >>>> >>>> Unable to obtain cpu_type >>>> >>>> >>>> >>>> Looking at op_cpu_type.h I see entries for >>>> >>>> >>>> >>>> CPU_PPC_E500MC, /**< e500mc */ >>>> >>>> CPU_PPC_E6500, /**< e6500 */ >>>> >>>> >>>> >>>> But no entry for the PPC E5500. The E5500 is very similar to e500mc and >> the E6500. Can support be added for this processor ? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Tom >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> |
From: Michael P. <mp...@re...> - 2016-07-11 22:11:57
|
On Mon, 11 Jul 2016, Beaman, Thomas wrote: > >> >> I don't see any ppc64/e6500 dir. Do you have the same git tree? >> https://sourceforge.net/p/oprofile/oprofile/ci/master/tree/events/ppc64/ > > I did some looking into this, and I have oprofile version 1.1.0 but my linux vendor (WindRiver linux) does add a patch called > > oprofile-wr-add-ppc64-e6500-support.patch > > which adds entries to the ppc64 event dir and updates the op_cpu_type.c file with a ppc64/e6500 entry. (very similar type of updates as your patch) Could this patch be posted here to review? William, I am a bit doubtful after looking at the code, whether we even support the e6500 at all. 1) In libop/op_cpu_type.c, the function __get_cpu_type does not have anything to support ppc32, so I don't see a path for 32bit ppc there. 2) In case e6500 runs in ppc64 mode, it probably jumps into _get_ppc64_cpu_type, where it constructs the path to the events file, however, it can point only into the ppc64 dir (libop/op_cpu_type.c, line 333). That might be why the WindRiver linux needs the additional patch. I don't have any similar CPU to test on. > > >> > > What you say is probably correct for intel, but from actual testing this does not appear to be the case for PowerPC. If I do not have the ppc64/e5500 entries the cpu is NOT detected. This is probably why Windriver has added the ppc64/e6500 patch. > > That might make sense, as it's been said above. However, if the hypothesis is right, we'd need some more fixes in order to enable the CPUs. >>> > > The problem with the script is my system would not accept sleep 0.2. I have changed it to sleep 1 and now it is working. I have attached the output files events.list, results.log and supported.list > Thanks, it looks fine. However, 123 out of 201 events give zero values. It does not have to be a problem. However, some events should return something. Could you please test ocount against some more cache-stressing command than sleep and test L1_CACHE_MISSES, L1_CACHE_LOAD_MISSES and L1_CACHE_STORE_MISSES? Also, please try out a simple test, whether L1_CACHE_MISSES = L1_CACHE_LOAD_MISSES + L1_CACHE_STORE_MISSES. Also, please try out, whether you can measure anything non-zero with CLK_FPU_DIV, when counting against a program doing floating point divisions. The FPU events are in E6500 only, not in E500MC. The same with the L1_CACHE_* events. However, there were some DL1_RELOADS and IL1_FETCH_RELOADS, but no L1_CACHE_* events, so this looks suspicious. Maybe E5500 has different event set than E6500. Maybe it is more similar to E500mc, maybe not. It would be really helpful to have an expert insight into the event sets availale. >>> Thanks, Michael |
From: Michael P. <mp...@re...> - 2016-07-12 20:47:44
|
On Tue, 12 Jul 2016, Beaman, Thomas wrote: > >> >> Hi Tom, >> >> Thanks for making the request to Windriver for the e6500 oprofile patch. >> >> Are there similar special patches in kernel being used to allow access to the >> e5500 performance monitoring hardware? I see references to e500 and >> e6500 in the mainline kernel (linux/arch/power/perf/e500-pmu.c and >> linux/arch/power/perf/e6500-pmu.c, but don't see anything for e5500. Does >> "perf list" work and list out events thave "[Hardware event]" or "[Kernel >> PMU event]" on the line? If the kernel support isn't there, then changes to >> the user-space oprofile isn't make much of a difference. >> >> -Will > > > Hi Will, > > So far I am only using Michaels patch plus a few hand edits I make, which allows detection of the cpu. > > I have attached the output of the "perf list" command. It does have some Hardware Events listed > > Tom > Since the `perf list` shows stalled-cycles-frontend and stalled-cycles-backend events, it seems it does not use the e6500-pmu.c file, since these events are specified in e500-pmu.c only. Tom, the question was whether WindRiver has some kernel patches for e5500 support or not. You may also try to see which PMU drivers are present in kallsyms: cat /proc/kallsyms | grep pmu | grep init If you see e5500 there, your kernel probably has some WindRiver-specific patch, since there is probably no init_e5500_pmu in the upstream kernel. Michael |
From: Beaman, T. <Tho...@xe...> - 2016-07-13 13:22:59
|
> -----Original Message----- > From: Michael Petlan [mailto:mp...@re...] > Sent: Tuesday, July 12, 2016 4:48 PM > To: Beaman, Thomas > Cc: William Cohen; opr...@li... > Subject: RE: oprofile support for PPC_E5500 > > On Tue, 12 Jul 2016, Beaman, Thomas wrote: > > > >> > >> Hi Tom, > >> > >> Thanks for making the request to Windriver for the e6500 oprofile patch. > >> > >> Are there similar special patches in kernel being used to allow > >> access to the > >> e5500 performance monitoring hardware? I see references to e500 and > >> e6500 in the mainline kernel (linux/arch/power/perf/e500-pmu.c and > >> linux/arch/power/perf/e6500-pmu.c, but don't see anything for e5500. > >> Does "perf list" work and list out events thave "[Hardware event]" or > >> "[Kernel PMU event]" on the line? If the kernel support isn't there, > >> then changes to the user-space oprofile isn't make much of a difference. > >> > >> -Will > > > > > > Hi Will, > > > > So far I am only using Michaels patch plus a few hand edits I make, which > allows detection of the cpu. > > > > I have attached the output of the "perf list" command. It does have > > some Hardware Events listed > > > > Tom > > > > Since the `perf list` shows stalled-cycles-frontend and stalled-cycles-backend > events, it seems it does not use the e6500-pmu.c file, since these events are > specified in e500-pmu.c only. > > Tom, the question was whether WindRiver has some kernel patches for > e5500 support or not. > > You may also try to see which PMU drivers are present in kallsyms: > > cat /proc/kallsyms | grep pmu | grep init > > If you see e5500 there, your kernel probably has some WindRiver-specific > patch, since there is probably no init_e5500_pmu in the upstream kernel. > > Michael Hi Michael, There are no specific WindRiver patches that I can see for the e5500 and there is no init_e5500 in kallsyms. How do you think we should proceed ? Thanks, Tom root@miopqt_250:~# cat /proc/kallsyms | grep pmu | grep init c000000000059de8 t .fsl_emb_pmu_event_init c00000000005acf0 t .init_e500_pmu c00000000005ade4 t .init_e6500_pmu c000000000c51f10 t __initcall_init_e500_pmuearly c000000000c51f18 t __initcall_init_e6500_pmuearly c000000000d3e480 d fsl_emb_pmu_event_init c000000000d3e5b8 d init_e500_pmu c000000000d3e5e8 d init_e6500_pmu |
From: Michael P. <mp...@re...> - 2016-07-13 14:28:24
Attachments:
cache_stressing.c
|
I have forgot the cache-stressing sample program. |
From: Beaman, T. <Tho...@xe...> - 2016-07-13 16:18:13
|
> -----Original Message----- > From: Michael Petlan [mailto:mp...@re...] > Sent: Wednesday, July 13, 2016 10:16 AM > To: Beaman, Thomas > Cc: William Cohen; opr...@li... > Subject: RE: oprofile support for PPC_E5500 > > On Wed, 13 Jul 2016, Beaman, Thomas wrote: > > > >> > >> Since the `perf list` shows stalled-cycles-frontend and > >> stalled-cycles-backend events, it seems it does not use the > >> e6500-pmu.c file, since these events are specified in e500-pmu.c only. > >> > >> Tom, the question was whether WindRiver has some kernel patches for > >> e5500 support or not. > >> > >> You may also try to see which PMU drivers are present in kallsyms: > >> > >> cat /proc/kallsyms | grep pmu | grep init > >> > >> If you see e5500 there, your kernel probably has some > >> WindRiver-specific patch, since there is probably no init_e5500_pmu in > the upstream kernel. > >> > >> Michael > > > > Hi Michael, > > > > There are no specific WindRiver patches that I can see for the e5500 and > there is no init_e5500 in kallsyms. How do you think we should proceed ? > > > > Thanks, > > Tom > > > > root@miopqt_250:~# cat /proc/kallsyms | grep pmu | grep init > > c000000000059de8 t .fsl_emb_pmu_event_init > > c00000000005acf0 t .init_e500_pmu > > c00000000005ade4 t .init_e6500_pmu > > c000000000c51f10 t __initcall_init_e500_pmuearly > > c000000000c51f18 t __initcall_init_e6500_pmuearly > > c000000000d3e480 d fsl_emb_pmu_event_init > > c000000000d3e5b8 d init_e500_pmu > > c000000000d3e5e8 d init_e6500_pmu > > > > > > > > Hi Tom, > > as William said, it would be nice to have the WindRiver oprofile patch posted > to the oprofile-list and incorporate it into upstream oprofile, in order to > eliminate the need of it. Could you please ask someone in WindRiver about > it? I have filed a request with Windriver to submit their e6500 patch for review, and they have responded they will look into it and get back to me. I will let you know what they say. > > Then, it would be nice to know the set of events supported by E5500 in order > to have correct events/ppc64/e5500/events file. In my patch, I supposed > that it has the same events as e6500, which is not probable. So it might either > have e500mc's events or it might have its own set. > > Since we don't have the sufficienf knowledge, I am trying to approximate to > the correct set. For that, I asked you to test the CLK_FPU_DIV against some > program that performs lots of FPU divisions and L1_CACHE_* events against > something that might be more cache_stressing than the tested 'sleep 1' > command. You may use my sample program I use (attached). > > As I wrote in some of the previous e-mails, the following from your > results.csv looks suspicious: > > DL1_RELOADS,18240,100.00 > IL1_FETCH_RELOADS,11714,100.00 > L1_STASH_HIT,0,100.00 > L1_STASH_REQ,0,100.00 > L1_CACHE_MISSES,0,100.00 > L1_CACHE_LOAD_MISSES,0,100.00 > L1_CACHE_STORE_MISSES,0,100.00 > > While DL1_RELOADS and IL1_FETCH_RELOADS events give some non-zero > results, the L1_CACHE_MISSES, L1_CACHE_LOAD_MISSES and > L1_CACHE_STORE_MISSES are zero. This is probably wrong. Since the > L1_CACHE_MISSES event and the LOAD/STORE brothers are e6500-only, I > guess they are a sign that e5500 cannot have the e6500 event set. You can > prove this guess by checking whether you are able to get non-zero values > here with cache-stressing or not. > Sorry I was not able to get you this data sooner, I got tied up in other matters. I compiled and ran your cache stress program and I think it proved your theory that the e5500 is not the same as the e6500 in this area. The results still show zero on the same L1 entries ./cache_stress 32384 Allocated 1061158912 bytes from addr 0xb8b43008 Doing 100000 memory operations. Finished 100000 memory operations. ./check_events.sh grep L1 results.log DL1_RELOADS,18561,100.00 IL1_FETCH_RELOADS,10777,100.00 L1_STASH_HIT,0,100.00 L1_STASH_REQ,0,100.00 L1_CACHE_MISSES,0,100.00 L1_CACHE_LOAD_MISSES,0,100.00 L1_CACHE_STORE_MISSES,0,100.00 L1_CACHE_IM,0,100.00 Also (the other L1 events showed the same type of results) ocount -e L1_STASH_HIT ./cache_stress 32384 Allocated 1061158912 bytes from addr 0xb8513008 Doing 100000 memory operations. Finished 100000 memory operations. Events were actively counted for 662947632 nanoseconds. Event counts (actual) for /opt/XRX_IOT/miopqt/cache_stress: Event Count % time counted L1_STASH_HIT 0 100.00 > Second thing I picked from your results is the CLK_FPU_DIV: > > It should count cycles spent in fdivs or fdiv instructions. So I'd try to test it by > something like: > > #include <stdio.h> > #include <stdlib.h> > int main(int argc, char *argv[]) > { > double a = atof(argv[1]); > double b = 3.14159265; > double c = a / b; > printf("res = %lf\n", c); > return 0; > } > > gcc -o div -O0 -g div.c > > Check whether it contains the fdif or fdivs instrucions by: > > objdump -d div > > If it contains the instructions, try to get a nonzero result from CLK_FPU_DIV: > > ocount -e CLK_FPU_DIV ./div 23445 > > > Thanks. > Michael > objdump shows there is one fdiv instruction in the program powerpc-wrs-linux-gnu-objdump -d div | grep -i fdiv 10000500: fc 0d 00 24 fdiv f0,f13,f0 root@miopqt_250:miopqt# ocount -e CLK_FPU_DIV ./div 23445 res = 7462.775290 Events were actively counted for 3338854 nanoseconds. Event counts (actual) for /opt/XRX_IOT/miopqt/div: Event Count % time counted CLK_FPU_DIV 1 100.00 Let me know what over data I can help collect. Thanks for your help on this, Tom |
From: Beaman, T. <Tho...@xe...> - 2016-07-18 20:21:34
|
> > Hi Tom, > > > > as William said, it would be nice to have the WindRiver oprofile patch > > posted to the oprofile-list and incorporate it into upstream oprofile, > > in order to eliminate the need of it. Could you please ask someone in > > WindRiver about it? > > I have filed a request with Windriver to submit their e6500 patch for review, > and they have responded they will look into it and get back to me. I will let > you know what they say. > > I have received an message back from Windriver on the oprofile e6500 patch. You can contact Ray Blackburn at ray...@wi... and reference case 00059721. He will be the initial contact. Tom |
From: Michael P. <mp...@re...> - 2016-07-13 14:31:17
|
On Wed, 13 Jul 2016, Beaman, Thomas wrote: > >> >> Since the `perf list` shows stalled-cycles-frontend and stalled-cycles-backend >> events, it seems it does not use the e6500-pmu.c file, since these events are >> specified in e500-pmu.c only. >> >> Tom, the question was whether WindRiver has some kernel patches for >> e5500 support or not. >> >> You may also try to see which PMU drivers are present in kallsyms: >> >> cat /proc/kallsyms | grep pmu | grep init >> >> If you see e5500 there, your kernel probably has some WindRiver-specific >> patch, since there is probably no init_e5500_pmu in the upstream kernel. >> >> Michael > > Hi Michael, > > There are no specific WindRiver patches that I can see for the e5500 and there is no init_e5500 in kallsyms. How do you think we should proceed ? > > Thanks, > Tom > > root@miopqt_250:~# cat /proc/kallsyms | grep pmu | grep init > c000000000059de8 t .fsl_emb_pmu_event_init > c00000000005acf0 t .init_e500_pmu > c00000000005ade4 t .init_e6500_pmu > c000000000c51f10 t __initcall_init_e500_pmuearly > c000000000c51f18 t __initcall_init_e6500_pmuearly > c000000000d3e480 d fsl_emb_pmu_event_init > c000000000d3e5b8 d init_e500_pmu > c000000000d3e5e8 d init_e6500_pmu > > > Hi Tom, as William said, it would be nice to have the WindRiver oprofile patch posted to the oprofile-list and incorporate it into upstream oprofile, in order to eliminate the need of it. Could you please ask someone in WindRiver about it? Then, it would be nice to know the set of events supported by E5500 in order to have correct events/ppc64/e5500/events file. In my patch, I supposed that it has the same events as e6500, which is not probable. So it might either have e500mc's events or it might have its own set. Since we don't have the sufficienf knowledge, I am trying to approximate to the correct set. For that, I asked you to test the CLK_FPU_DIV against some program that performs lots of FPU divisions and L1_CACHE_* events against something that might be more cache_stressing than the tested 'sleep 1' command. You may use my sample program I use (attached). As I wrote in some of the previous e-mails, the following from your results.csv looks suspicious: DL1_RELOADS,18240,100.00 IL1_FETCH_RELOADS,11714,100.00 L1_STASH_HIT,0,100.00 L1_STASH_REQ,0,100.00 L1_CACHE_MISSES,0,100.00 L1_CACHE_LOAD_MISSES,0,100.00 L1_CACHE_STORE_MISSES,0,100.00 While DL1_RELOADS and IL1_FETCH_RELOADS events give some non-zero results, the L1_CACHE_MISSES, L1_CACHE_LOAD_MISSES and L1_CACHE_STORE_MISSES are zero. This is probably wrong. Since the L1_CACHE_MISSES event and the LOAD/STORE brothers are e6500-only, I guess they are a sign that e5500 cannot have the e6500 event set. You can prove this guess by checking whether you are able to get non-zero values here with cache-stressing or not. Second thing I picked from your results is the CLK_FPU_DIV: It should count cycles spent in fdivs or fdiv instructions. So I'd try to test it by something like: #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { double a = atof(argv[1]); double b = 3.14159265; double c = a / b; printf("res = %lf\n", c); return 0; } gcc -o div -O0 -g div.c Check whether it contains the fdif or fdivs instrucions by: objdump -d div If it contains the instructions, try to get a nonzero result from CLK_FPU_DIV: ocount -e CLK_FPU_DIV ./div 23445 Thanks. Michael |
From: Michael P. <mp...@re...> - 2016-10-04 15:12:55
|
Just a reminder, what's the state of this issue? Have we obtained the WindRiver patch? Michael On Wed, 13 Jul 2016, Michael Petlan wrote: > On Wed, 13 Jul 2016, Beaman, Thomas wrote: >> >>> >>> Since the `perf list` shows stalled-cycles-frontend and stalled-cycles-backend >>> events, it seems it does not use the e6500-pmu.c file, since these events are >>> specified in e500-pmu.c only. >>> >>> Tom, the question was whether WindRiver has some kernel patches for >>> e5500 support or not. >>> >>> You may also try to see which PMU drivers are present in kallsyms: >>> >>> cat /proc/kallsyms | grep pmu | grep init >>> >>> If you see e5500 there, your kernel probably has some WindRiver-specific >>> patch, since there is probably no init_e5500_pmu in the upstream kernel. >>> >>> Michael >> >> Hi Michael, >> >> There are no specific WindRiver patches that I can see for the e5500 and there is no init_e5500 in kallsyms. How do you think we should proceed ? >> >> Thanks, >> Tom >> >> root@miopqt_250:~# cat /proc/kallsyms | grep pmu | grep init >> c000000000059de8 t .fsl_emb_pmu_event_init >> c00000000005acf0 t .init_e500_pmu >> c00000000005ade4 t .init_e6500_pmu >> c000000000c51f10 t __initcall_init_e500_pmuearly >> c000000000c51f18 t __initcall_init_e6500_pmuearly >> c000000000d3e480 d fsl_emb_pmu_event_init >> c000000000d3e5b8 d init_e500_pmu >> c000000000d3e5e8 d init_e6500_pmu >> >> >> > > Hi Tom, > > as William said, it would be nice to have the WindRiver oprofile patch posted > to the oprofile-list and incorporate it into upstream oprofile, in order to > eliminate the need of it. Could you please ask someone in WindRiver about it? > > Then, it would be nice to know the set of events supported by E5500 in order to > have correct events/ppc64/e5500/events file. In my patch, I supposed that it has > the same events as e6500, which is not probable. So it might either have e500mc's > events or it might have its own set. > > Since we don't have the sufficienf knowledge, I am trying to approximate to the > correct set. For that, I asked you to test the CLK_FPU_DIV against some program > that performs lots of FPU divisions and L1_CACHE_* events against something that > might be more cache_stressing than the tested 'sleep 1' command. You may use my > sample program I use (attached). > > As I wrote in some of the previous e-mails, the following from your results.csv > looks suspicious: > > DL1_RELOADS,18240,100.00 > IL1_FETCH_RELOADS,11714,100.00 > L1_STASH_HIT,0,100.00 > L1_STASH_REQ,0,100.00 > L1_CACHE_MISSES,0,100.00 > L1_CACHE_LOAD_MISSES,0,100.00 > L1_CACHE_STORE_MISSES,0,100.00 > > While DL1_RELOADS and IL1_FETCH_RELOADS events give some non-zero results, the > L1_CACHE_MISSES, L1_CACHE_LOAD_MISSES and L1_CACHE_STORE_MISSES are zero. This > is probably wrong. Since the L1_CACHE_MISSES event and the LOAD/STORE brothers > are e6500-only, I guess they are a sign that e5500 cannot have the e6500 event > set. You can prove this guess by checking whether you are able to get non-zero > values here with cache-stressing or not. > > Second thing I picked from your results is the CLK_FPU_DIV: > > It should count cycles spent in fdivs or fdiv instructions. So I'd try to test > it by something like: > > #include <stdio.h> > #include <stdlib.h> > int main(int argc, char *argv[]) > { > double a = atof(argv[1]); > double b = 3.14159265; > double c = a / b; > printf("res = %lf\n", c); > return 0; > } > > gcc -o div -O0 -g div.c > > Check whether it contains the fdif or fdivs instrucions by: > > objdump -d div > > If it contains the instructions, try to get a nonzero result from CLK_FPU_DIV: > > ocount -e CLK_FPU_DIV ./div 23445 > > > Thanks. > Michael > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity planning > reports.http://sdm.link/zohodev2dev > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |