lkml.org 
[lkml]   [2009]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] perf_counter: powerpc: allow use of limited-function counters

* 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


\
 
 \ /
  Last update: 2009-04-29 15:47    [W:0.098 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site