Re: [PATCH] basic perf support for sparc

[Ingo Molnar]

* Jens Axboe <jens.axboe@xxxxxxxxxx> wrote:

> On Fri, Sep 04 2009, Jens Axboe wrote:
> > On Thu, Sep 03 2009, David Miller wrote:
> > > From: Ingo Molnar <mingo@xxxxxxx>
> > > Date: Fri, 4 Sep 2009 07:02:56 +0200
> > > 
> > > > 
> > > > * David Miller <davem@xxxxxxxxxxxxx> wrote:
> > > > 
> > > >> Does this build for you without adding an
> > > >> arch/sparc/include/asm/perf_counter.h that looks
> > > >> something like the following?
> > > >> 
> > > >> #ifndef _ASM_SPARC_PERF_COUNTER_H
> > > >> #define _ASM_SPARC_PERF_COUNTER_H
> > > >> 
> > > >> #define PERF_COUNTER_INDEX_OFFSET	0
> > > >> 
> > > >> #endif
> > > >> 
> > > >> Or is this somehow now required in the -tip trees?
> > > > 
> > > > This used to be required but i recently fixed this (and that fix is 
> > > > upstream as well) via:
> > > > 
> > > >   f738eb1: perf_counter: Fix the PARISC build
> > > > 
> > > > there's now a default define of 0 so you dont have to define it and 
> > > > can leave out this chunk.
> > > > 
> > > > ( That index is only interesting if the architecture has a way to 
> > > >   allow unprivileged user-space to access counter registers 
> > > >   directly. In that case the index reflects the offset from the 
> > > >   (constantly changing) dynamix index which we put into the mmap 
> > > >   header. With Sparc not having a hw-PMU implementation this index 
> > > >   is entirely uninteresting at this stage. )
> > > 
> > > But you still do need at least an empty perf_counter.h file
> > > right?  Jens must have left the file out of his submission
> > > by accident, and that's what I'm trying to get to the bottom
> > > of here :-)
> > > 
> > > I assume there was a similar change to deal with references to
> > > set_perf_counter_pending() too or is at least a NOP definition
> > > still needed?
> > 
> > It wasn't required when I built and used it (and sent the 
> > patch), I used the posted patch as-is. It's been a few weeks 
> > since I last updated and ran that box, let me double check after 
> > morning coffee and send you a fresh patch (if needed) :-)
> 
> It seems I had a left-over arch/sparc/include/asm/perf_counter.h 
> from earlier experiments that was never checked in, so that is why 
> it worked for me. include/linux/sched.h does:
> 
> #ifdef CONFIG_PERF_COUNTERS
> # include <asm/perf_counter.h>
> #endif
> 
> so that's no way around an empty stub file. Updated patch below, 
> this is what I have been using.

That stub is not wasted: it will be filled in with real arch hw-PMU 
details, once that's implemented too.

hw-PMU support has its advantages: it can provide NMI sampling that 
allows 'perf report' to pierce irqs-off critical sections, and it 
also gives access to non-time based metrics such as instructions, 
cache-misses, etc. - depending on what the CPU can do.

That way you can tell at a glance what a workload does:

 aldebaran:~> perf stat ./hackbench 10
 Time: 0.109

 Performance counter stats for './hackbench 10':

    1191.574039  task-clock-msecs         #      7.768 CPUs 
          50363  context-switches         #      0.042 M/sec
           4249  CPU-migrations           #      0.004 M/sec
          17710  page-faults              #      0.015 M/sec
     3600730931  cycles                   #   3021.827 M/sec
     1573681316  instructions             #      0.437 IPC  
       15394883  cache-references         #     12.920 M/sec
        5005241  cache-misses             #      4.201 M/sec

    0.153389368  seconds time elapsed

without hw-PMU support it looks like this:

 venus:~> perf stat ./hackbench 1
 Time: 7.600

 Performance counter stats for './hackbench 1':

   28218.316944  task-clock-ticks     #       3.590 CPU utilization factor
          62700  context-switches     #       0.002 M/sec
          11112  CPU-migrations       #       0.000 M/sec
           1919  page-faults          #       0.000 M/sec
  <not counted>  cycles              
  <not counted>  instructions        
  <not counted>  cache-references    
  <not counted>  cache-misses        

 Wall-clock time elapsed:  7860.000004 msecs

The soft stats and time measurements work just fine - the hardware 
metrics are not counted.

	Ingo
--
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/