Re: [PATCH] Add support for Intel Netburst (e.g., Pentium P4) to operf

[Maynard J. <may...@us...>]

On 05/21/2013 07:12 AM, Gilles Allard wrote:
> On Monday, May 20, 2013 08:36:42 AM you wrote:
>> You should be able to compare opcontrol and operf results pretty easily by
>> doing something like the following:
>>
>> 1. rm /root/.oprofile/daemonrc (delete opcontrol cache file so we're
>> starting from scratch) 2. rm -rf oprofile_data (to make sure opreport
>> doesn't "see" profile data collected by previous runs of operf) 3.
>> opcontrol --reset
>> 4. opcontrol --start --no-vmlinux --separate=lib,kernel -e
>> GLOBAL_POWER_EVENTS:100000 5. Run a specific benchmark or application that
>> you can trust will yield repeatable results. 6. opcontrol --deinit
>> 7. opreport --symbols > op1.out
>>
>> 8. operf -e GLOBAL_POWER_EVENTS:100000 <your benchmark or app>
>> 9. opreport --symbols > op2.out
>> 10. Compare op1.out and op2.out -- the number of samples per binary file
>> should be pretty close.
>>
>> Thanks!
>> -Maynard
> 
> I cannot say that the results in both cases ( "operf-based" & "opcontrol-
> based" profiler ) are pretty close : overall number of samples & number of 
> samples for each binary file are different for each test ( at least for the 
> lines showing a great number of samples ) but the percentages for each binary 
> file are rather similar.
> I think that this can be partly explained by the fact that stopping the 
> application is done by a mouse click on a button ( this application is a small 
> Qt widget )
Gilles,
The oprofile-tests have some simple workloads used in the oprofile testsuite.  Attached is the "memcpyt.c" workload, slightly modified to run a bit longer than normal.  This little testcase should give you better repeatable results.  If you can find time to run opcontrol and operf against it, I would appreciate it.
> 
> I can send a copy of the results printed by opreport if needed ( about 210 
> lines each )
> 
> But another problem occurs during the test with operf. In the first release, 
> the application processes its argument when it receives "SIGUSR1"; its 
> behaviour was as expected with "opcontrol" but the test program doesn't 
> receive the signal when under control of "operf" ( so I had to slightly modify 
> the code to get some results ). The Oprofile manual doesn't say anything about 
> this point and I may have missed something.
I'm not quite sure I understand exactly what problem you're having, but a simple test I did of adding a SIGUSR1 handler to the memcpyt.c program seemed to work OK (when I sent the USR1 signal to memcpyt while operf was profiling it).  Please work up a minimal testcase that exhibits the problem and post it as a new thread to this list, with all details we'll need to reproducee.

Thanks.

-Maynard

> 
> Let me know if you wish to get a copy of the results of these tests.
> 
> Gilles Allard
>