From: SourceForge.net <no...@so...> - 2010-09-21 16:17:37
|
Bugs item #3072766, was opened at 2010-09-21 09:17 Message generated for change (Tracker Item Submitted) made by stick_figure You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3072766&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Reid Kleckner (stick_figure) Assigned to: Nobody/Anonymous (nobody) Summary: opreport appears to not support changing events Initial Comment: Original mailing list thread: http://marc.info/?l=oprofile-list&m=128508347501923&w=2 If a user starts a profile run with one set of counters, and then changes the counters they want to profile without shutting down the daemon, opreport reports on the old counters. Here is a sample session demonstrating the confusion: [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. 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 opcontrol --status reports that the new counters are being used, even though they didn't show up in the report: [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 Maynard suggested that the solution might be to keep a second cache of the set of performance counters being monitored, but I am not familiar enough to explain more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3072766&group_id=16191 |
From: SourceForge.net <no...@so...> - 2010-09-21 16:18:46
|
Bugs item #3072766, was opened at 2010-09-21 09:17 Message generated for change (Comment added) made by stick_figure You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3072766&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Reid Kleckner (stick_figure) Assigned to: Nobody/Anonymous (nobody) Summary: opreport appears to not support changing events Initial Comment: Original mailing list thread: http://marc.info/?l=oprofile-list&m=128508347501923&w=2 If a user starts a profile run with one set of counters, and then changes the counters they want to profile without shutting down the daemon, opreport reports on the old counters. Here is a sample session demonstrating the confusion: [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. 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 opcontrol --status reports that the new counters are being used, even though they didn't show up in the report: [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 Maynard suggested that the solution might be to keep a second cache of the set of performance counters being monitored, but I am not familiar enough to explain more. ---------------------------------------------------------------------- >Comment By: Reid Kleckner (stick_figure) Date: 2010-09-21 09:18 Message: I should add that the correct way for the user to get the desired behavior is to use --shutdown instead of --stop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3072766&group_id=16191 |
From: SourceForge.net <no...@so...> - 2011-04-20 21:26:13
|
Bugs item #3072766, was opened at 2010-09-21 11:17 Message generated for change (Comment added) made by maynardj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3072766&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Reid Kleckner (stick_figure) Assigned to: Nobody/Anonymous (nobody) Summary: opreport appears to not support changing events Initial Comment: Original mailing list thread: http://marc.info/?l=oprofile-list&m=128508347501923&w=2 If a user starts a profile run with one set of counters, and then changes the counters they want to profile without shutting down the daemon, opreport reports on the old counters. Here is a sample session demonstrating the confusion: [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. 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 opcontrol --status reports that the new counters are being used, even though they didn't show up in the report: [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 Maynard suggested that the solution might be to keep a second cache of the set of performance counters being monitored, but I am not familiar enough to explain more. ---------------------------------------------------------------------- >Comment By: Maynard Johnson (maynardj) Date: 2011-04-20 16:26 Message: Reid, I just posted a patch for this problem to the oprofile mailing list, and I asked Will Cohen to review it. Could you review the patch, too, please? I'll attach it to this bug for convenience, but if you have review comments, I'd prefer you make them on the mailing list if possible. ---------------------------------------------------------------------- Comment By: Reid Kleckner (stick_figure) Date: 2010-09-21 11:18 Message: I should add that the correct way for the user to get the desired behavior is to use --shutdown instead of --stop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3072766&group_id=16191 |
From: SourceForge.net <no...@so...> - 2011-05-19 12:05:14
|
Bugs item #3072766, was opened at 2010-09-21 11:17 Message generated for change (Settings changed) made by maynardj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3072766&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Reid Kleckner (stick_figure) >Assigned to: Maynard Johnson (maynardj) Summary: opreport appears to not support changing events Initial Comment: Original mailing list thread: http://marc.info/?l=oprofile-list&m=128508347501923&w=2 If a user starts a profile run with one set of counters, and then changes the counters they want to profile without shutting down the daemon, opreport reports on the old counters. Here is a sample session demonstrating the confusion: [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. 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 opcontrol --status reports that the new counters are being used, even though they didn't show up in the report: [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 Maynard suggested that the solution might be to keep a second cache of the set of performance counters being monitored, but I am not familiar enough to explain more. ---------------------------------------------------------------------- Comment By: Maynard Johnson (maynardj) Date: 2011-04-20 16:26 Message: Reid, I just posted a patch for this problem to the oprofile mailing list, and I asked Will Cohen to review it. Could you review the patch, too, please? I'll attach it to this bug for convenience, but if you have review comments, I'd prefer you make them on the mailing list if possible. ---------------------------------------------------------------------- Comment By: Reid Kleckner (stick_figure) Date: 2010-09-21 11:18 Message: I should add that the correct way for the user to get the desired behavior is to use --shutdown instead of --stop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3072766&group_id=16191 |
From: SourceForge.net <no...@so...> - 2011-05-25 21:21:53
|
Bugs item #3072766, was opened at 2010-09-21 11:17 Message generated for change (Comment added) made by maynardj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3072766&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Reid Kleckner (stick_figure) Assigned to: Maynard Johnson (maynardj) Summary: opreport appears to not support changing events Initial Comment: Original mailing list thread: http://marc.info/?l=oprofile-list&m=128508347501923&w=2 If a user starts a profile run with one set of counters, and then changes the counters they want to profile without shutting down the daemon, opreport reports on the old counters. Here is a sample session demonstrating the confusion: [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. 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 opcontrol --status reports that the new counters are being used, even though they didn't show up in the report: [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 Maynard suggested that the solution might be to keep a second cache of the set of performance counters being monitored, but I am not familiar enough to explain more. ---------------------------------------------------------------------- >Comment By: Maynard Johnson (maynardj) Date: 2011-05-25 16:21 Message: The patch I initially posted on April 20 went through a few rounds of review. The final version (4th) was posted, ack'ed, and committed on May 25. Marking this bug as "Fixed". ---------------------------------------------------------------------- Comment By: Maynard Johnson (maynardj) Date: 2011-04-20 16:26 Message: Reid, I just posted a patch for this problem to the oprofile mailing list, and I asked Will Cohen to review it. Could you review the patch, too, please? I'll attach it to this bug for convenience, but if you have review comments, I'd prefer you make them on the mailing list if possible. ---------------------------------------------------------------------- Comment By: Reid Kleckner (stick_figure) Date: 2010-09-21 11:18 Message: I should add that the correct way for the user to get the desired behavior is to use --shutdown instead of --stop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3072766&group_id=16191 |
From: SourceForge.net <no...@so...> - 2011-08-12 14:06:29
|
Bugs item #3072766, was opened at 2010-09-21 11:17 Message generated for change (Settings changed) made by ssuthiku You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3072766&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Reid Kleckner (stick_figure) Assigned to: Maynard Johnson (maynardj) Summary: opreport appears to not support changing events Initial Comment: Original mailing list thread: http://marc.info/?l=oprofile-list&m=128508347501923&w=2 If a user starts a profile run with one set of counters, and then changes the counters they want to profile without shutting down the daemon, opreport reports on the old counters. Here is a sample session demonstrating the confusion: [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. 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 opcontrol --status reports that the new counters are being used, even though they didn't show up in the report: [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 Maynard suggested that the solution might be to keep a second cache of the set of performance counters being monitored, but I am not familiar enough to explain more. ---------------------------------------------------------------------- Comment By: Maynard Johnson (maynardj) Date: 2011-05-25 16:21 Message: The patch I initially posted on April 20 went through a few rounds of review. The final version (4th) was posted, ack'ed, and committed on May 25. Marking this bug as "Fixed". ---------------------------------------------------------------------- Comment By: Maynard Johnson (maynardj) Date: 2011-04-20 16:26 Message: Reid, I just posted a patch for this problem to the oprofile mailing list, and I asked Will Cohen to review it. Could you review the patch, too, please? I'll attach it to this bug for convenience, but if you have review comments, I'd prefer you make them on the mailing list if possible. ---------------------------------------------------------------------- Comment By: Reid Kleckner (stick_figure) Date: 2010-09-21 11:18 Message: I should add that the correct way for the user to get the desired behavior is to use --shutdown instead of --stop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3072766&group_id=16191 |