Messages in this thread | | | Date | Wed, 29 Apr 2009 15:09:15 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |