It's possible some of the counters in the group could be
disabled when sampling member of the event group is reading
the rest via PERF_SAMPLE_READ sample type processing. Disabled
counters could then produce wrong numbers.
Fixing that by reading only enabled counters for PERF_SAMPLE_READ
sample type processing.
Signed-off-by: Jiri Olsa <jo...@redhat.com>
Cc: Arnaldo Carvalho de Melo <a...@ghostprotocols.net>
Cc: Peter Zijlstra <a.p.zijls...@chello.nl>
Cc: Ingo Molnar <mi...@elte.hu>
Cc: Paul Mackerras <pau...@samba.org>
Cc: Corey Ashford <cjash...@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweis...@gmail.com>
Cc: Namhyung Kim <namhy...@kernel.org>
---
kernel/events/core.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 32aec40..5220d01 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4012,12 +4012,24 @@ static void perf_output_read_group(struct
perf_output_handle *handle,
__output_copy(handle, values, n * sizeof(u64));
list_for_each_entry(sub, &leader->sibling_list, group_entry) {
+ u64 value = 0;
n = 0;
- if (sub != event)
- sub->pmu->read(sub);
+ /*
+ * We are NOT interested in disabled counters,
+ * giving us strange values and keeping us from
+ * good night sleep!!!
+ */
+ if (sub->state > PERF_EVENT_STATE_OFF) {
+
+ if (sub != event)
+ sub->pmu->read(sub);
+
+ value = perf_event_count(sub);
+ }
+
+ values[n++] = value;
- values[n++] = perf_event_count(sub);
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(sub);
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
