incorrect perf counters

[riya khanna]

Thanks!

This is how I'm measuring perf counters delta (attached perf.stp).
However, this may add unnecessary overhead.

Additionally, perf.stp seems to work correctly when I attach to a
process name with single PID. However, if I attach to a process name
(e.g. apache httpd) that has multiple PIDs (e.g. apache workers, some
spawned at runtime to serve requests), then counters reported are
incorrect (sometimes 0). "perf stat" tool reports correct counters.

I was wondering if "probe perf" collects per-cpu counters or across
all CPUs? Is the perf state transferred/saved upon cpu/context switch?
How can I accomplish this similar to what "perf stat" command line
tool does?

-Riya

On Wed, Jul 27, 2016 at 11:59 AM, Frank Ch. Eigler <fche@redhat.com> wrote:
>
> riyakhanna1983 wrote:
>
>> Is is possible to enable/disable counters on a function entry/exit?
>
> Enabling/disabling is a relatively large amount of work.  If you just
> want a *delta* between function entry/exit, you could accumulate that
> thusly:
>
> stap -e '
> global counts
> probe perf.sw.cpu_clock.counter("foo") {}
> probe process.function("*").return { counts <<< @perf("foo") - @entry(@perf("foo")) }
> ' -c /bin/ls
>
> ... but actually it seems we're not implementing @entry(@perf(...))
> correctly just now, so you may need to do this instead:
>
> global counts, zoo%
> probe perf.sw.cpu_clock.counter("foo") {}
> probe process.function("main").call { zoo[tid()] = @perf("foo") }
> probe process.function("main").return { counts <<< @perf("foo") - zoo[tid()] }
> ' -c /bin/ls
>
> - FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: perf.stp
Type: application/octet-stream
Size: 1929 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20160727/8fa16e42/attachment.obj>