Messages in this thread | | | Date | Mon, 22 Jun 2009 13:59:28 +0200 | From | Ingo Molnar <> | Subject | Re: IV.2 - Features impacting all counters |
| |
> 2/ Features impacting all counters > > On some PMU models, e.g., Itanium, they are certain features which > have an influence on all counters that are active. For instance, > there is a way to restrict monitoring to a range of continuous > code or data addresses using both some PMU registers and the debug > registers. > > Given that the API exposes events (counters) as independent of > each other, I wonder how range restriction could be implemented.
A solution is to make it a per-counter attribute and fail to schedule multiple counters at the same time when these constraints differ.
> Similarly, on Itanium, there are global behaviors. For instance, > on counter overflow the entire PMU freezes all at once. That seems > to be contradictory with the design of the API which creates the > illusion of independence. > > What solutions do you propose?
We propose the same solution as last time: live with the small imprecisions caused by such hardware limitations. We submit that natural workload noise is probably far bigger than any such effect. We could certainly list it as a platform limitation.
| |