[<prev] [next>] [day] [month] [year] [list]
Message-ID: <q2lbd4cb8901004090322g1efb36cesc39a6848ab403e9f@mail.gmail.com>
Date: Fri, 9 Apr 2010 12:22:59 +0200
From: Stephane Eranian <eranian@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, mingo@...e.hu, paulus@...ba.org,
davem@...emloft.net, robert.richter@....com,
perfmon2-devel@...ts.sf.net, eranian@...il.com,
Frederic Weisbecker <fweisbec@...il.com>
Subject: [BUG] perf_events: PERF_FORMAT_GROUP fails
Hi,
I have been running some tests where I count and I am
using PERF_FORMAT_GROUP. I want to extract all counts
in one read().
It turns out that this does not work as expected. I would expect
that if I create an event group, I can ALWAYS read it with a single
read(). Turns out, it depends on the state of the events.
If the events are still attached to a task then the read() returns
the expected data which is:
/*
* { u64 nr;
* { u64 time_enabled; } && PERF_FORMAT_ENABLED
* { u64 time_running; } && PERF_FORMAT_RUNNING
* { u64 value;
* { u64 id; } && PERF_FORMAT_ID
* } cntr[nr];
*/
But if you read once the monitored task has died, i.e., events are detached,
then all you get is the data for the leader of the group yet the value
of nr still
shows all the members of the group.
Here is an example with 2 events + ENABLED+RUNNING:
- task active, events attached: read()=40 (5* 8,
5=nr+enabled+running+2*value), nr=2
- task died, event detached: read()=32 (4*8 =
nr+enabled+running+value) yet nr=2
Seems to me the events need to be linked in sibling_list regardless of the state
they are in. And there is mismatch in how nr_siblings and sibling_list
are managed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists