RE: [RFC][PATCH 2/6] perf, arch: Rework perf_event_index()

From: Oleg Strikov
Date: Tue Nov 22 2011 - 07:01:23 EST


Also, please do not forget that enabling the userspace access to the counters may not only create some problems
to the profilers like Perf/OProfile but could also trash the kernel with the interrupts.

The PerfEvents subsystem enables the interrupts for the counters overflows.
If the userspace application can change the counter value the right way -- it could generate a lot of interrupts per second.

Oleg

-----Original Message-----
From: Will Deacon [mailto:will.deacon@xxxxxxx]
Sent: Tuesday, November 22, 2011 3:52 PM
To: Oleg Strikov
Cc: Peter Zijlstra; mingo@xxxxxxx; William Cohen; linux-kernel@xxxxxxxxxxxxxxx; Michael Cree; Deng-Cheng Zhu; Anton Blanchard; Eric B Munson; Heiko Carstens; Paul Mundt; David S. Miller; Richard Kuo; Stephane Eranian; Arun Sharma; Vince Weaver
Subject: Re: [RFC][PATCH 2/6] perf, arch: Rework perf_event_index()

On Tue, Nov 22, 2011 at 11:49:41AM +0000, Oleg Strikov wrote:
> > The user-readable clock will first appear in Cortex-A15, so the code for that still needs to hit mainline before I can look at doing this in perf.
>
> This could be very useful. I think that the cycles counter covers the 90% of all the in-app profiler needs.

Well, it's slightly different to the cycle counter in that it will continue to count when the core is idle. The PMU cycle counter may stop when you issue a WFI. The frequency of the clock is also unlikely to be the same as the CPU clock.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/