RE: oprofile support for PPC_E5500

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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oprofile-list
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot