Discussion:
oprofile support for PPC_E5500
(too old to reply)
Beaman, Thomas
2016-07-06 14:26:20 UTC
Permalink
Raw Message
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
William Cohen
2016-07-07 14:33:22 UTC
Permalink
Raw Message
Post by Beaman, Thomas
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
Beaman, Thomas
2016-07-07 17:48:54 UTC
Permalink
Raw Message
-----Original Message-----
From: William Cohen [mailto:***@redhat.com]
Sent: Thursday, July 07, 2016 10:33 AM
To: Beaman, Thomas; oprofile-***@lists.sourceforge.net
Subject: Re: oprofile support for PPC_E5500
Post by Beaman, Thomas
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
Michael Petlan
2016-07-07 14:47:38 UTC
Permalink
Raw Message
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
Post by Beaman, Thomas
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
 
 
Michael Petlan
2016-07-08 17:15:57 UTC
Permalink
Raw Message
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/

[***@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:

[***@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-----
Sent: Thursday, July 07, 2016 10:48 AM
To: Beaman, Thomas
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
Post by Beaman, Thomas
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
 
 
Beaman, Thomas
2016-07-11 18:36:55 UTC
Permalink
Raw Message
Post by Beaman, Thomas
-----Original Message-----
Sent: Friday, July 08, 2016 1:16 PM
To: Beaman, Thomas
Subject: RE: oprofile support for PPC_E5500
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)
Post by Beaman, Thomas
7450 e300 e500 e500mc e500v2 e5500 e6500
970 970MP architected_events_v1 power4 power5 power5+ power5++
power6 power7 power8
{ "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.
Post by Beaman, Thomas
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.
***@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.
Post by Beaman, Thomas
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.
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
Post by Beaman, Thomas
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-----
Sent: Thursday, July 07, 2016 10:48 AM
To: Beaman, Thomas
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
Post by Beaman, Thomas
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 ?
Post by Beaman, Thomas
Thanks,
Tom
William Cohen
2016-07-11 19:49:14 UTC
Permalink
Raw Message
Post by Beaman, Thomas
Post by Beaman, Thomas
-----Original Message-----
Sent: Friday, July 08, 2016 1:16 PM
To: Beaman, Thomas
Subject: RE: oprofile support for PPC_E5500
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
Post by Beaman, Thomas
Post by Beaman, Thomas
7450 e300 e500 e500mc e500v2 e5500 e6500
970 970MP architected_events_v1 power4 power5 power5+ power5++
power6 power7 power8
{ "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.
Post by Beaman, Thomas
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.
e5500
but I can only get this if I have ppc64/e5500 entries in op_cpu_type.c and the ppc64/e5500 directory.
Post by Beaman, Thomas
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.
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
Post by Beaman, Thomas
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-----
Sent: Thursday, July 07, 2016 10:48 AM
To: Beaman, Thomas
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
Post by Beaman, Thomas
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 ?
Post by Beaman, Thomas
Thanks,
Tom
Michael Petlan
2016-07-12 20:47:30 UTC
Permalink
Raw Message
Post by Beaman, Thomas
Post by William Cohen
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
Beaman, Thomas
2016-07-13 13:22:50 UTC
Permalink
Raw Message
Post by Beaman, Thomas
-----Original Message-----
Sent: Tuesday, July 12, 2016 4:48 PM
To: Beaman, Thomas
Subject: RE: oprofile support for PPC_E5500
Post by Beaman, Thomas
Post by William Cohen
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.
Post by Beaman, Thomas
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.
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

***@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
Beaman, Thomas
2016-07-13 15:36:21 UTC
Permalink
Raw Message
Post by Beaman, Thomas
-----Original Message-----
Sent: Wednesday, July 13, 2016 10:16 AM
To: Beaman, Thomas
Subject: RE: oprofile support for PPC_E5500
Post by Michael Petlan
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.
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.
Post by Michael Petlan
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
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.
Post by Beaman, Thomas
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
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
Post by Beaman, Thomas
It should count cycles spent in fdivs or fdiv instructions. So I'd try to test it by
#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
objdump -d 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


***@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
Beaman, Thomas
2016-07-18 20:21:26 UTC
Permalink
Raw Message
Post by Beaman, Thomas
Post by William Cohen
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 ***@windriver.com and reference case 00059721. He will be the initial contact.

Tom
Michael Petlan
2016-07-13 14:22:06 UTC
Permalink
Raw Message
I have forgot the cache-stressing sample program.
Michael Petlan
2016-10-04 14:56:04 UTC
Permalink
Raw Message
Just a reminder, what's the state of this issue? Have we obtained the WindRiver
patch?

Michael
Post by William Cohen
Post by Michael Petlan
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.
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
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
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.
It should count cycles spent in fdivs or fdiv instructions. So I'd try to test
#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
objdump -d 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
https://lists.sourceforge.net/lists/listinfo/oprofile-list
Michael Petlan
2016-07-11 22:11:45 UTC
Permalink
Raw Message
Post by Beaman, Thomas
Post by Michael Petlan
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.
Post by Beaman, Thomas
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.
Post by Beaman, Thomas
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
Loading...