Messages in this thread | | | Date | Tue, 23 Jun 2009 19:51:10 +0200 | Subject | Re: I.2 - Grouping | From | stephane eranian <> |
| |
Corey,
On Tue, Jun 23, 2009 at 12:04 AM, Corey Ashford<cjashfor@linux.vnet.ibm.com> wrote: > stephane eranian wrote: >> >> On Mon, Jun 22, 2009 at 1:50 PM, Ingo Molnar<mingo@elte.hu> 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? >> >> >>>> Events in a group are guaranteed to be active on the PMU at the >>>> 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 >>>> practical. >>> >>> Groups are there to support heavily constrained PMUs, and for them >>> this is the only way, as there is no simple linear expression for >>> how many counters one can load on the PMU. >>> >> But then, does that mean that users need to be aware of constraints >> 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). >> > > Stephane, if you were to just place into groups those events which must be > correlated, and just leave all of the others not grouped, wouldn't this > solve the problem? The kernel would be free to schedule the other events > how and when it can, but would guarantee that your correlated events are on > the PMU simultaneously. > It would work. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |