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


On 07/29/2016 09:44 AM, riya khanna wrote:
> In tapsets.cxx, emit_perf_read_handler() emits
> "_stp_perf_read(smp_processor_id(), i)" to read perf counters values.
> However, for non-systemwide perf counters (i.e.  with stp->system_wide
> = 0), "_stp_perf_init()" calls perf_event_create_kernel_counter() with
> cpu = -1.
> 
> Does this mean that probe perf.xx.process("y").counter("z") will only
> be read on current CPU? Because I see 0s being reported for hw
> counters.

That is strange.  However, if you look at the implementation of
_stp_perf_read, it doesn't actually use that "ncpu" parameter.  Since
this is a thread event, perf itself should be saving and restoring
counter values whenever that thread reschedules, even to other cpus.

However, I'm not sure we're handling multiple threads or multiple
processes correctly.  In _stp_perf_init, it just returns if the
per_thread_event is already configured.  It appears to me that the
stap_perf_probes[] array is a fixed allocation for each counter, so then
whichever task is found first will own it exclusively.

I thought we already had a bug about this, and even fixed it, but I
can't find that information now... :/


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