Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1683375 > unrolled thread

Re: tracing/kprobes: [Bug] Identical timestamps on two kprobes that are few instructions apart

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: tracing/kprobes: [Bug] Identical timestamps on two kprobes that  are few instructions apart Steven Rostedt <rostedt@goodmis.org> - 2017-07-07 21:10 +0200
    Re: tracing/kprobes: [Bug] Identical timestamps on two kprobes that  are few instructions apart Arun Kalyanasundaram <arunkaly@google.com> - 2017-07-08 01:10 +0200
      Re: tracing/kprobes: [Bug] Identical timestamps on two kprobes that  are few instructions apart Masami Hiramatsu <mhiramat@kernel.org> - 2017-07-10 02:20 +0200
        Re: tracing/kprobes: [Bug] Identical timestamps on two kprobes that  are few instructions apart Arun Kalyanasundaram <arunkaly@google.com> - 2017-07-10 19:40 +0200

#1683375 — Re: tracing/kprobes: [Bug] Identical timestamps on two kprobes that are few instructions apart

On Fri, 7 Jul 2017 10:34:48 -0700
Arun Kalyanasundaram <arunkaly@google.com> wrote:

> Hi,
> 
> 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
> probes.
> 
> 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.
> 
> comm,tid,cpu,time,event,ip,sym
> stream,62182,[064],3020935.384132080,probe:kprobe1,ffffffffb36399f1,__schedule
> stream,62182,[064],3020935.384132080,probe:kprobe2,ffffffffb36399fd,__schedule
> 
> 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

[toc] | [next] | [standalone]

#1683458

Hi Steven,

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@goodmis.org> wrote:
> On Fri, 7 Jul 2017 10:34:48 -0700
> Arun Kalyanasundaram <arunkaly@google.com> wrote:
>
>> Hi,
>>
>> 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
>> probes.
>>
>> 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.
>>
>> comm,tid,cpu,time,event,ip,sym
>> stream,62182,[064],3020935.384132080,probe:kprobe1,ffffffffb36399f1,__schedule
>> stream,62182,[064],3020935.384132080,probe:kprobe2,ffffffffb36399fd,__schedule
>>
>> 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

[toc] | [prev] | [next] | [standalone]

#1683868

Hello Arun,

On Fri, 7 Jul 2017 16:06:40 -0700
Arun Kalyanasundaram <arunkaly@google.com> wrote:

> Hi Steven,
> 
> 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.

Ok, so this happens with ftrace+trace-cmd too.
If you run it on x86-64, could you add "-C x86-tsc" and check still
it happens? If not, I guess it happens when it adjusts timestamp.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

[toc] | [prev] | [next] | [standalone]

#1684530

Hi Masama,

Thank you for looking into this.
You are right, I don't see the issue when my trace_clock = x86-tsc.

I tried with other clocks and apparently, I only see this when my
clock is either perf or global.
You mentioned this happens when "it adjusts timestamp", so does that
mean this is an expected behavior in this case?

I am running this on a haswell x86 architecture with 72 cores.

Thank you,
- Arun




On Sun, Jul 9, 2017 at 5:18 PM, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> Hello Arun,
>
> On Fri, 7 Jul 2017 16:06:40 -0700
> Arun Kalyanasundaram <arunkaly@google.com> wrote:
>
>> Hi Steven,
>>
>> 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.
>
> Ok, so this happens with ftrace+trace-cmd too.
> If you run it on x86-64, could you add "-C x86-tsc" and check still
> it happens? If not, I guess it happens when it adjusts timestamp.
>
> Thank you,
>
> --
> Masami Hiramatsu <mhiramat@kernel.org>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web