Messages in this thread | | | Date | Mon, 22 Jun 2009 13:57:34 +0200 | From | Ingo Molnar <> | Subject | Re: II.2 - Event knowledge missing |
| |
> 2/ Event knowledge missing > > There are constraints on events in Intel processors. Different > constraints do exist on AMD64 processors, especially with > uncore-releated events.
You raise the issue of uncore events in IV.1, but let us reply here primarily.
Un-core counters and events seem to be somewhat un-interesting to us. (Patches from those who find them interesting are welcome of course!)
So they werent in the first line of PMU features to cherry-pick from.
The main problem with uncore events is that they are per physical package, and hence tying a piece of physical metric exposed via them to a particular workload is hard - unless full-system analysis is performed. 'Task driven' metrics seem far more useful to performance analysis (and those are the preferred analysis method of most user-space developers), as they allow particularized sampling and allow the tight connection between workload and metric.
If, despite our expecations, uncore events prove to be useful, popular and required elements of performance analysis, they can be supported in perfcounters via various levels:
- a special raw ID range on x86, only to per CPU counters. The low-level implementation reserves the uncore PMCs, so overlapping allocation (and interaction between the cores via the MSRs) is not possible.
- generic enumeration with full tooling support, time-sharing and the whole set of features. The low-level backend would time-share the resource between interested CPUs.
There is no limitation in the perfcounters design that somehow makes uncore events harder to support. The uncore counters _themselves_ are limited to begin with - so rich features cannot be offered on top of them.
> In your model, those need to be taken care of by the kernel. > Should the kernel make the wrong decision, there would be no > work-around for user tools. Take the example I outlined just above > with Intel fixed counters.
Yes. Why should there be a work-around for user tools if the fix is for the kernel? We don't try to work around random driver bugs in userspace either, we simply fix the kernel.
> The current code-base does not have any constrained event support, > therefore bogus counts may be returned depending on the event > measured.
Then we'll need to grow some when we run into them :-)
| |