Messages in this thread | | | Date | Wed, 29 Apr 2009 13:19:34 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 04/29] x86/perfcounters: rework pmc_amd_save_disable_all() and pmc_amd_restore_all() |
| |
* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Wed, 2009-04-29 at 13:11 +0200, Ingo Molnar wrote: > > * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > > > > > On Wed, 2009-04-29 at 12:47 +0200, Robert Richter wrote: > > > > MSR reads and writes are expensive. This patch adds checks to avoid > > > > its usage where possible. > > > > > > save_disable_all() > > > enable(1) > > > restore_all() > > > > > > would not correctly enable 1 with the below modification as we do > > > not write the configuration into the msr, on which restore relies, > > > as it only toggles the _ENABLE bit. > > > > > > That said, I'm not sure if that's really an issue, but its why the > > > does does as it does. > > > > > > A better abstraction could perhaps avoid this issue all-together. > > > > Could we remove the disable-all facility altogether and make the > > core code NMI-safe? The current approach wont scale on CPUs that > > dont have global-disable features. > > > > disable-all was arguably a hack i introduced and which spread too > > far. Can you see a conceptual need for it? > > power suffers the same issue and simply iterates the things like > amd does now. > > The thing is, with a global disable you get slightly better > coupling, so in that respect it might be nice to have.
ok. With system-wide profiling there's no global disable/enable in the fastpath. Do we have any of them in the per task counter fastpath?
Ingo
| |