Re: [PATCH] perf_counter: powerpc: allow use of limited-function counters

[Ingo Molnar <mingo@elte.hu>]

* Paul Mackerras <paulus@samba.org> wrote:

> POWER5+ and POWER6 have two hardware counters with limited 
> functionality: PMC5 counts instructions completed in run state and 
> PMC6 counts cycles in run state.  (Run state is the state when a 
> hardware RUN bit is 1; the idle task clears RUN while waiting for 
> work to do and sets it when there is work to do.)
> 
> These counters can't be written to by the kernel, can't generate 
> interrupts, and don't obey the freeze conditions.  That means we 
> can only use them for per-task counters (where we know we'll 
> always be in run state; we can't put a per-task counter on an idle 
> task), and only if we don't want interrupts and we do want to 
> count in all processor modes.
> 
> Obviously some counters can't go on a limited hardware counter, 
> but there are also situations where we can only put a counter on a 
> limited hardware counter - if there are already counters on that 
> exclude some processor modes and we want to put on a per-task 
> cycle or instruction counter that doesn't exclude any processor 
> mode, it could go on if it can use a limited hardware counter.
> 
> To keep track of these constraints, this adds a flags argument to 
> the processor-specific get_alternatives() functions, with three 
> bits defined: one to say that we can accept alternative event 
> codes that go on limited counters, one to say we only want 
> alternatives on limited counters, and one to say that this is a 
> per-task counter and therefore events that are gated by run state 
> are equivalent to those that aren't (e.g. a "cycles" event is 
> equivalent to a "cycles in run state" event).  These flags are 
> computed for each counter and stored in the 
> counter->hw.counter_base field (slightly wonky name for what it 
> does, but it was an existing unused field).
> 
> Since the limited counters don't freeze when we freeze the other 
> counters, we need some special handling to avoid getting skew 
> between things counted on the limited counters and those counted 
> on normal counters.  To minimize this skew, if we are using any 
> limited counters, we read PMC5 and PMC6 immediately after setting 
> and clearing the freeze bit.  This is done in a single asm in the 
> new write_mmcr0() function.
> 
> The code here is specific to PMC5 and PMC6 being the limited 
> hardware counters.  Being more general (e.g. having a bitmap of 
> limited hardware counter numbers) would have meant more complex 
> code to read the limited counters when freezing and unfreezing the 
> normal counters, with conditional branches, which would have 
> increased the skew.  Since it isn't necessary for the code to be 
> more general at this stage, it isn't.
> 
> This also extends the back-ends for POWER5+ and POWER6 to be able 
> to handle up to 6 counters rather than the 4 they previously 
> handled.
> 
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
>  arch/powerpc/include/asm/perf_counter.h |   13 ++-
>  arch/powerpc/kernel/perf_counter.c      |  297 +++++++++++++++++++++++++++----
>  arch/powerpc/kernel/power4-pmu.c        |    3 +-
>  arch/powerpc/kernel/power5+-pmu.c       |  117 ++++++++++--
>  arch/powerpc/kernel/power5-pmu.c        |    3 +-
>  arch/powerpc/kernel/power6-pmu.c        |  119 +++++++++++--
>  arch/powerpc/kernel/ppc970-pmu.c        |    3 +-
>  7 files changed, 479 insertions(+), 76 deletions(-)

Applied, thanks Paul!

[ Note, i saw some fuzz in those files. It applied fine but maybe 
  you have some local changes in them that are not in 
  tip:perfcounters/core yet? You might want to double check that. ]

	Ingo