On Friday, November 18, 2011 11:12:02 PM Andres Freund wrote:
> On Friday, November 18, 2011 09:16:01 PM Kevin Grittner wrote:
> > Andres Freund <andres@anarazel.de> wrote:
> > > When doing line-level profiles I would suggest looking at the
> > > instructions.
> >
> > What's the best way to do that?
>
> I think opannotate -a -s produces output with instructions/code
> intermingled.
>
> > > I don't think cache line contention is the most likely candidate
> > > here. Simple cache-misses seem far more likely. In combination
> > > with pipeline stalls...
> > >
> > > Newer cpus (nehalem+) can measure stalled cycles which can be
> > > really useful when analyzing performance. I don't remember how to
> > > do that with oprofile right now though as I use perf these days
> > > (its -e stalled-cycles{frontend|backend} there}).
> >
> > When I run oprofile, I still always go back to this post by Tom:
> > http://archives.postgresql.org/pgsql-performance/2009-06/msg00154.php
>
> Hrm. I am on the train and for unknown reasons the only sensible working
> protocols are smtp + pop.... Waiting.... Waiting....
> Sorry, too slow/high latency atm. I wrote everything below and another mail
> and the page still hasn't loaded.
>
> oprofile can produces graphes as well (--callgraph). for both tools you
> need -fno-omit-frame-pointers to get usable graphs.
>
> > Can anyone provide such a "cheat sheet" for perf? I could give that
> > a try if I knew how.
>
> Unfortunately for sensible results the kernel needs to be rather new.
> I would say > 2.6.28 or so (just guessed).
>
> # to record activity
> perf record [-g|--call-graph] program|-p pid
>
> # to view a summation
> perf report
> # get heaps of stats from something
> perf stat -ddd someprogram|-p pid
> # show whats the system executing overall
> perf top -az
>
> # get help
> perf help (record|report|annotate|stat|...)
>
...
I forgot that there is also
# get a list of event types
perf list
# measure somethign for a specidif event
perf (record|stat|top) -e some_event_type
Andres