RE: oprofile support for PPC_E5500

Michael Petlan <[email protected]>
Newsgroups gmane.linux.oprofile
Message-ID <alpine.LRH.2.20.1607112332170.10992@Diego>
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

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.