Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Mar 2006 13:50:03 -0500 (EST)
From:      Andrew Gallatin <gallatin@cs.duke.edu>
To:        "Joseph Koshy" <joseph.koshy@gmail.com>
Cc:        Robert Watson <rwatson@freebsd.org>, current@freebsd.org
Subject:   Re: The sixty second pmc howto
Message-ID:  <17440.19163.8504.103892@grasshopper.cs.duke.edu>
In-Reply-To: <84dead720603211040h3db11614v31ae5d7d9a0c1a28@mail.gmail.com>
References:  <20060223143856.O9642@fledge.watson.org> <17405.53911.686306.362353@grasshopper.cs.duke.edu> <84dead720603202346t6fe1e94cve033bf002dffa90a@mail.gmail.com> <17440.17965.497455.777452@grasshopper.cs.duke.edu> <84dead720603211040h3db11614v31ae5d7d9a0c1a28@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

Joseph Koshy writes:
 > > For a few modules, I suppose it is OK.  But it makes it hard to
 > > see the "big picture" when a number of modules are loaded.
 > > Is there any chance you have enough information to hack
 > > together a view similar to oprofile's opreport -l? Or
 > > (even better) opreport -ld
 > 
 > Can you post what that looks like?

Sure:

% opreport -l 
CPU: AMD64 processors, speed 2612.09 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 860000
samples  %        image name               app name                 symbol name
29056    56.1458  vmlinux                  vmlinux                  copy_user_generic_c
2116      4.0888  vmlinux                  vmlinux                  schedule
1032      1.9942  vmlinux                  vmlinux                  skb_dequeue
846       1.6348  vmlinux                  vmlinux                  task_rq_lock
763       1.4744  vmlinux                  vmlinux                  __wake_up_common
718       1.3874  vmlinux                  vmlinux                  try_to_wake_up
608       1.1749  vmlinux                  vmlinux                  resched_task
<...>
6         0.0116  forcedeth                forcedeth                (no symbols)
3         0.0058  libc-2.3.4.so            gdmgreeter               (no symbols)
<...>


% opreport -ld
CPU: AMD64 processors, speed 2612.09 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 860000
vma      samples  %        image name               app name                 symbol name
ffffffff801e961a 29056    56.1458  vmlinux                  vmlinux                  copy_user_generic_c
  ffffffff801e961a 5         0.0172
  ffffffff801e961c 3         0.0103
  ffffffff801e9622 28731    98.8815
  ffffffff801e9625 280       0.9637
  ffffffff801e9627 33        0.1136
  ffffffff801e9629 3         0.0103
  ffffffff801e962b 1         0.0034
<.....>
0000000000000000 6         0.0116  forcedeth                forcedeth                (no symbols)
  0000000000000e1c 3        50.0000
  0000000000000e4c 1        16.6667
  00000000000011a9 2        33.3333

<.....>
0000000000000000 3         0.0058  libc-2.3.4.so            gdmgreeter               (no symbols)
  00000000000689f5 1        33.3333
  0000000000068dfe 1        33.3333
  0000000000080644 1        33.3333


The cool thing about opreport -ld is that it allows you
to narrow things down to a single line of code inside a
function.

 > There is a lot of information in hwpmc's event log, but
 > gprof(1) is only able to deal with one (object) file at
 > a time.  This restriction is likely to pinch even more
 > when callgraphs are implemented.

Yes..  I wonder if gprof might be too restrictive, and it
might be better to re-invent a custom interface like oprofile
has, and dcpi had.

Drew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17440.19163.8504.103892>