Messages in this thread | | | Subject | Re: [patch] Performance Counters for Linux, v4 | From | Peter Zijlstra <> | Date | Tue, 16 Dec 2008 15:22:21 +0100 |
| |
On Mon, 2008-12-15 at 23:11 +1100, Paul Mackerras wrote: > Ingo Molnar writes: > > > We are pleased to announce the v4 release of our performance counters > > subsystem implementation. > > Looking at the code, I am wondering what you are planning to do to > support machines that have constraints on what sets of events can be > counted simultaneously. Currently you have the core code calling > counter->hw_ops->hw_perf_counter_enable which can't return an error. > The core expects it to be able to add any counter regardless of what > event it's counting, subject only to a maximum number of counters. > I assume you're going to change that. > > I think the core should put together a list of counters and counter > groups that it would like to have on the PMU simultaneously and then > make one call to the arch layer to ask if that is possible. That > could either return success or failure. If it returns failure then > the core needs to ask for something less, or something different. I'm > not sure how the core should choose what to ask for instead, though.
I think the constraint set should be applied when we add to a group, if when we add a counter to the group, the result isn't schedulable anymore, we should fail the group addition - and thereby the counter creation.
This would leave us with groups that are always schedulable in an atomic fashion.
>From what I understand the code RRs groups (co-scheduling groups where possible) (ungrouped counter is a group of one), this means that with the above addition you'd have the needed control over things.
If you need things to be atomic, create a single group, if you're fine with RR time-sharing, create multiple.
This seems to leave a hole where multiple monitors collide and create multiple groups unaware of each-other - could we plug this hole with a group attribute?
| |