Re: [BUG(?)] perf_events: combining multiple tracepoint events into a group produces no counts on member events

[Corey Ashford <cjashfor@linux.vnet.ibm.com>]

On 11/30/2010 05:00 PM, Corey Ashford wrote:
>
> Hi,
>
> I'm not sure that what I'm seeing is a bug, or was something intentional.
>
> If I place multiple tracepoint events into a group and measure counts of
> these events on a process, I get no counts for the tracepoint events
> other than the group leader.
>
> Is this expected behavior?
>
> It's not clear to me why this should be the case; grouping shouldn't
> have any ill effects on tracepoint events, from my understanding.
>
> I noticed this because my private version of the perf tool has the event
> group patch https://lkml.org/lkml/2010/11/24/584 as well as the patch
> which fixes the parsing of multiple tracepoint events in the same -e
> switch: https://lkml.org/lkml/2010/11/30/460
>
> When I dig into the code a bit, I find that each event opens
> successfully, so that's not the problem. If I disable the grouping, then
> I get counts for all of the tracepoint events.

False alarm.  I found a bug in my forwarded-ported version of the event 
grouping patch for perf stat.  I was setting the attr->disabled bit for 
all of the events instead of just the group leader, when forking off the 
command.

Software events, tracepoints, and hardware events all work when grouped 
now.  Sorry, I should have been more thorough in testing this on other 
types of events.  I had thought I had it working with hardware events, 
and it was, but only if I attached to an existing process, not when 
forking off a new command.  Anyway, if I had tested with hardware events 
in the same way I had tested tracepoints I would have seen the problem.

So the patch mentioned above, https://lkml.org/lkml/2010/11/24/584, has 
a bug, but since it didn't get committed, I suppose it's not a problem. 
  If anyone is still interested, I can post a v4 of that patch.

Sorry for the bother!

- Corey