Re: OProfile not resetting properly

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

Reid Kleckner wrote:
> I'm trying to create a project using oprofile in a class I'm teaching,
> and I want to measure the various things, such as the branch
> mispredict rate, cache miss rate, CPI, etc, on the Nehalems we have
> available.
> 
> The problem I've having is that I can reset the current session data,
> start the profiler, run my benchmark, stop the profiler, and print the
> results with oprofile, but if I try to do another run with different
> counters, opreport ignores me.  Here's a shell transcript to give you
> an idea:
> 
> [reid@muikyl profiling]$ sudo opcontrol --reset && sudo opcontrol
> --start -e CPU_CLK_UNHALTED:400000 -e INST_RETIRED:400000 &&
> ./matrix_multiply && sudo opcontrol --stop
> Signalling daemon... done
> Profiler running.
> Setup
> Running matrix_multiply_run()...
> Elapsed execution time: 11.496006 sec
> Stopping profiling.
> [reid@muikyl profiling]$ opreport ./matrix_multiply
> Overflow stats not available
> CPU: Intel Core/i7, speed 1596 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a
> unit mask of 0x00 (No unit mask) count 1000000
> Counted INST_RETIRED events (number of instructions retired) with a
> unit mask of 0x01 (any_p instructions retired) count 1000000
> CPU_CLK_UNHALT...|INST_RETIRED:1...|
>   samples|      %|  samples|      %|
> ------------------------------------
>     22925 100.000      9056 100.000 matrix_multiply
> [reid@muikyl profiling]$ sudo opcontrol --reset && sudo opcontrol
> --start -e L1D:400000 -e MEM_INST_RETIRED:400000 && ./matrix_multiply
> && sudo opcontrol --stop
> Signalling daemon... done
> Profiler running.

Note ^^^^ the profiler daemon is still running.  The --stop option tells the oprofile daemon to temporarily stop.  Then, when you issue --start, it restarts with the same profiling parameters it was initially started with.  To restart the daemon with new profiling parameters, issue --shutdown instead of --stop.  This will not only stop profiling, but also end the oprofile daemon process.


> Setup
> Running matrix_multiply_run()...
> Elapsed execution time: 11.494934 sec
> Stopping profiling.
> [reid@muikyl profiling]$ opreport ./matrix_multiplyOverflow stats not available
> CPU: Intel Core/i7, speed 1596 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a
> unit mask of 0x00 (No unit mask) count 1000000
> Counted INST_RETIRED events (number of instructions retired) with a
> unit mask of 0x01 (any_p instructions retired) count 1000000
> CPU_CLK_UNHALT...|INST_RETIRED:1...|
>   samples|      %|  samples|      %|
> ------------------------------------
>     22919 100.000      9056 100.000 matrix_multiply
> 
> 
> Am I using oprofile incorrectly?  The only way for me to get it to
> print the data from the new counters is to completely --deinit and
> --init oprofile from scratch.
> 
> Also, I think it's interesting that the data is different from run to
> run, which suggests to me that it is actually profiling with the old
> counters.  opcontrol --status claims to use the new counters, though:
> 
> [reid@muikyl profiling]$ sudo opcontrol --status
> Daemon running: pid 2341
> Event 0: L1D:400000:1:1:1
> Event 1: MEM_INST_RETIRED:400000:1:1:1
> Separate options: none
> vmlinux file: none
> Image filter: none
> Call-graph depth: 0
Yeah, this isn't ideal, but currently we only use one cache file to store profiling parameters entered via opcontrol.  Maybe we should have a second file that stores the parameters being used by the running daemon.  Then 'opcontrol --status' would read that file if the daemon is running; otherwise it would read the setup cache file.

Please open a bug and request this change.

-Maynard
> 
> Is this a known bug, or a usage error?
> 
> Thanks,
> Reid
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> oprofile-list mailing list
> opr...@li...
> https://lists.sourceforge.net/lists/listinfo/oprofile-list