On Mon, Jun 22, 2009 at 1:50 PM, Ingo Molnar<mingo@xxxxxxx> wrote:2/ Grouping
By design, an event can only be part of one group at a time.
As I read this again, another question came up. Is the statement
above also true for the group leader?
But then, does that mean that users need to be aware of constraintsEvents in a group are guaranteed to be active on the PMU at theGroups are there to support heavily constrained PMUs, and for them
same time. That means a group cannot have more events than there
are available counters on the PMU. Tools may want to know the
number of counters available in order to group their events
accordingly, such that reliable ratios could be computed. It seems
the only way to know this is by trial and error. This is not
this is the only way, as there is no simple linear expression for
how many counters one can load on the PMU.
to form groups. Group are formed by users. I thought, the whole point
of the API was to hide that kind of hardware complexity.
Groups are needed when sampling, e.g., PERF_SAMPLE_GROUP.
For instance, I sample the IP and the values of the other events in
my group. Grouping looks like the only way to sampling on Itanium
branch buffers (BTB), for instance. You program an event in a generic
counter which counts the number of entries recorded in the buffer.
Thus, to sample the BTB, you sample on this event, when it overflows
you grab the content of the BTB. Here, the event and the BTB are tied
together. You cannot count the event in one group, and have the BTB
in another one (BTB = 1 config reg + 32 data registers + 1 position reg).