[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090904064418.GB29829@elte.hu>
Date: Fri, 4 Sep 2009 08:44:18 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Jens Axboe <jens.axboe@...cle.com>
Cc: David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
a.p.zijlstra@...llo.nl, fweisbec@...il.com
Subject: Re: [PATCH] basic perf support for sparc
* Jens Axboe <jens.axboe@...cle.com> wrote:
> On Fri, Sep 04 2009, Jens Axboe wrote:
> > On Thu, Sep 03 2009, David Miller wrote:
> > > From: Ingo Molnar <mingo@...e.hu>
> > > Date: Fri, 4 Sep 2009 07:02:56 +0200
> > >
> > > >
> > > > * David Miller <davem@...emloft.net> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists