[RFC PATCH 08/15] ARM: perf: remove unnecessary armpmu->stop
Will Deacon
will.deacon at arm.com
Mon Aug 22 16:12:48 EDT 2011
On Mon, Aug 22, 2011 at 07:36:18PM +0100, Ashwin Chaugule wrote:
> Hello,
Hi Ashwin,
> >> From: Mark Rutland
> >>
> >> As armpmu_disable will call armpmu->stop when the last event has been
> >> removed, this is pointless and simply adds to the noise when debugging.
> >> Additionally, due to this call occurring in a preemptible context, this
> >> is problematic for per-cpu locking of PMU registers (where we will
> >> attempt to access per-cpu spinlock for use with raw_spin_lock_irqsave).
> >>
> >> This patch removes the call to armpmu->stop.
> >>
> >> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> >> Reviewed-by: Will Deacon <will.deacon at arm.com>
> >> ---
> >> arch/arm/kernel/perf_event.c | 1 -
> >> 1 files changed, 0 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> >> index 9d6ac99..5ce6c33 100644
> >> --- a/arch/arm/kernel/perf_event.c
> >> +++ b/arch/arm/kernel/perf_event.c
> >> @@ -396,7 +396,6 @@ armpmu_release_hardware(void)
> >> free_irq(irq, NULL);
> >> }
> >>
> >> - armpmu->stop();
> >> release_pmu(ARM_PMU_DEVICE_CPU);
>
>
> Makes sense. On a similar note, I've been wondering why we need to loop
> through all events in armpmu_enable() ?
>
> Wouldn't the event->add call have taken care of armpmu->enable prior to
> calling armpmu_enable() ?
Hmm, I think you might be right. armpmu->enable is called from armpmu_start,
which is called from armpmu->add whenever a new event is added. The current
redundancy is likely a hangover from before we had the PERF_EF_*/PERF_HES_*
flags.
> I think we just need an armpmu->start(). What are your thoughts ?
Yes, conditional on armpmu->num_events > 0. I'll give it a spin and add it to
my perf-updates branch if I don't see any regressions.
Cheers,
Will
More information about the linux-arm-kernel
mailing list