Messages in this thread | | | Subject | Re: [RFC][PATCH 00/11] perf pmu interface -v2 | From | Peter Zijlstra <> | Date | Mon, 28 Jun 2010 17:13:29 +0200 |
| |
On Sat, 2010-06-26 at 09:22 -0700, Corey Ashford wrote:
> These patches look like they are really taking us in the right > direction. Thanks for all your effort on this!
Yeah, although I seem to have managed to wreck all architectures tested so far (I found some iffy on x86 too), I guess I need to carefully look at things.
> As for the "hardware write batching", can you describe a bit more about > what you have in mind there? I wonder if this might have something to > do with accounting for PMU hardware which is slow to access, for > example, via I2C via an internal bridge.
Right, so the write batching is basically delaying writing out the PMU state to hardware until pmu::pmu_enable() time. It avoids having to re-program the hardware when, due to a scheduling constraint, we have to move counters around.
So say, we context switch a task, and remove the old events and add the new ones under a single pmu::pmu_disable()/::pmu_enable() pair, we will only hit the hardware twice (once to disable, once to enable), instead of for each individual ::del()/::add().
For this to work we need to have an association between a context and a pmu, otherwise its very hard to know what pmu to disable/enable; the alternative is all of them which isn't very attractive.
Then again, it doesn't make sense to have task-counters on an I2C attached PMU simply because writing to the PMU could cause context switches.
| |