#225 operf should record throttling/multiplexing

[Maynard Johnson]

The operf program currently is able to detect when the kernel throttles the sample rate, printing a message to that effect at the end of the operf run. However, when post-processing tools (e.g., opreport) are used at a later time, there's no indication that throttling occurred, so the user may get a skewed impression of the profile data. operf should record the fact that throttling took place. The opcontrol-based profiler uses a "stats" directory under <session-dir>/samples/current. I propose we also create a "stats" directory when operf runs. A "throttling" file could be created when operf detects throttling; then opreport and other pp tools can look for that file and display a message (similar to how we currently display a message about buffer overflows).

Related to this issue is that operf does NOT detect when multiplexing occurs. We should add that capability by setting the proper bits in the config attr; e.g,

attr->read_format = attr->read_format = PERF_FORMAT_TOTAL_TIME_ENABLED |
PERF_FORMAT_TOTAL_TIME_RUNNING |
PERF_FORMAT_ID;

and then reading the perf_events fd for each configure event and checking if the 'time enabled' is equal to the 'total time running. If not equal, a "multiplexed" file should be created under the new "stats" dir, and the pp tools can look for such a file and print an appropriate message when found.

[Carl Love]

I (cel@linux.vnet.ibm.com) posted a proposed patch for this issue was posted to the mailing list

[PATCH] operf, add throttling and multiplexing stats
Date: 01/18/2013 03:51:57 PM

patch is awaiting community feedback and review.

Carl Love

[Maynard Johnson]

Fix committed on Jan 23, 2013.