This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: incorrect perf counters


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

Attachment: perf.stp
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]