Messages in this thread |  | | | Date | Thu, 11 Mar 2010 16:45:46 +0100 | | From | Robert Richter <> | | Subject | Re: [PATCH 0/9] oprofile, perf, x86: introduce new functions to reserve perfctrs |
| |
On 11.03.10 13:47:16, Ingo Molnar wrote: > * Peter Zijlstra <peterz@infradead.org> wrote: > > Alternatively, could we maybe further simplify this reservation into: > > > > int reserve_pmu(void); > > void release_pmu(void); > > > > And not bother with anything finer grained. > > Yeah, that looks quite a bit simpler.
It does not solve the current problem that some parts of the pmu *are* used simultaneously by different subsystems. But, even if only perf would be used in the kernel you still can't be sure that all parts of the pmu are available to be used, you simply don't have it under your control. So why such limitations as an 'int reserve_pmu(int index)' is almost the same but provides much more flexibility?
The question already arose if the watchdog would use perf permanently and thus would block oprofile by making it unusable. The current reservation code would provide a framework to solves this, sharing perfctrs with watchdog, perf and oprofile. And, since the pmu becomes more and more features other than perfctrs, why shouldn't it be possible to run one feature with perf and the other with oprofile?
> It's all about making it easier to live with legacies anyway - all modern > facilities will use perf events to access the PMU.
Scheduling events with perf is also 'some sort' of reservation, so this code could be moved later into perf at all. In this case we also will have to be able to reserve single counters or features by its index.
For now, I don't think it is possible to change oprofile to use perf in a big bang. This will disrupt oprofile users. I want to do the switch to perf in a series of small changes and patch sets to make sure, oprofile will not break. And this new reservation code is a step towards perf.
-Robert
-- Advanced Micro Devices, Inc. Operating System Research Center email: robert.richter@amd.com
|  |