Re: tracing/kprobes: [Bug] Identical timestamps on two kprobes that are few instructions apart
From: Arun Kalyanasundaram
Date: Fri Jul 07 2017 - 19:07:08 EST
Thank you very much for your reply. I am using kernel - v4.12-rc3.
I did something like this and see the issue:
# trace-cmd record -e kprobes:s1 -e kprobes:s2 -- taskset -c 0 my_program
# ./trace-cmd report -t --cpu 0
The issue is pretty intermittent and only happens when there are a lot
of samples, and so "my_program" generates a few hundred threads. Any
pointers on debugging this would be very helpful, or please let me
know if you want me to collect any log messages.
On Fri, Jul 7, 2017 at 12:01 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> On Fri, 7 Jul 2017 10:34:48 -0700
> Arun Kalyanasundaram <arunkaly@xxxxxxxxxx> wrote:
>> I am trying to use kprobes to time a few kernel functions. However, when I
>> add two kprobes on a function that are a few instructions apart, I
>> sometimes get the same timestamp (measured in nano seconds) on the two
>> For example, if I add the two probes as follows,
>> 1) perf probe -a "kprobe1=__schedule"
>> 2) perf probe -a "kprobe2=__schedule+12"
>> I then use "perf record" on a multi-threaded benchmark (e.g. stream:
>> https://www.cs.virginia.edu/stream/) to collect samples. I then see the
>> same timestamp on kprobe1 and kprobe2 for the same thread running on the
>> same CPU. Following is an example of the output showing the same timestamp
>> on the two probes.
>> Since it happens intermittently, I am wondering if there is some sort of
>> race condition here. Please let me know if this is an expected behavior or
>> is there something wrong in the way I use kprobes.
> I don't see this with ftrace. What kernel are you using?
> # cd /sys/kernel/debug/tracing
> # echo perf > trace_clock
> # echo 'p:s1 __schedule' > kprobe_events
> # echo 'p:s2 __schedule+12' >> kprobe_events
> # echo 1 > events/kprobes/enable
> # cd
> # trace-cmd extract
> # trace-cmd report -t --cpu 0 | less
> I didn't see anything where they had the same timestamps.
> -- Steve