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

Groups > linux.kernel > #1565508 > unrolled thread

Re: [PATCH v5 0/2] perf probe: add sdt probes arguments into the uprobe cmd string

Started byRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
First post2017-01-24 08:00 +0100
Last post2017-01-24 09:40 +0100
Articles 3 — 2 participants

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: [PATCH v5 0/2] perf probe: add sdt probes arguments into the  uprobe cmd string Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> - 2017-01-24 08:00 +0100
    Re: [PATCH v5 0/2] perf probe: add sdt probes arguments into the  uprobe cmd string Ingo Molnar <mingo@kernel.org> - 2017-01-24 09:30 +0100
      Re: [PATCH v5 0/2] perf probe: add sdt probes arguments into the  uprobe cmd string Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> - 2017-01-24 09:40 +0100

#1565508 — Re: [PATCH v5 0/2] perf probe: add sdt probes arguments into the uprobe cmd string

FromRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Date2017-01-24 08:00 +0100
SubjectRe: [PATCH v5 0/2] perf probe: add sdt probes arguments into the uprobe cmd string
Message-ID<t33fc-T4-5@gated-at.bofh.it>

On Wednesday 14 December 2016 01:06 PM, Ingo Molnar wrote:
> * Alexis Berlemont <alexis.berlemont@gmail.com> wrote:
>
>> Hi Masami,
>>
>> Many thanks for your mail.
>>
>> Here is another patch set which tries to fix the points you mentioned:
>>
>> * Skip the arguments containing a constant ($123); 
>> * Review the code in charge of the register renaming (search for '%'
>>   and parse it);
>> * Minor changes (print the argument in case of error, skipping, check
>>   the sdt arg type index);
>>
>> Many thanks,
>>
>> Alexis.
>>
>> Alexis Berlemont (2):
>>   perf sdt: add scanning of sdt probles arguments
>>   perf probe: add sdt probes arguments into the uprobe cmd string
> I'd like to hijack this thread to report an SDT oddity - one of my boxen reports 
> lots of SDT tracepoints in 'perf list':
>
>   mem:<addr>[/len][:access]                          [Hardware breakpoint]
>
>   sdt_libc:lll_lock_wait_private                     [SDT event]
>   sdt_libc:longjmp                                   [SDT event]
>   sdt_libc:longjmp_target                            [SDT event]
>   sdt_libc:memory_arena_new                          [SDT event]
>   sdt_libc:memory_arena_retry                        [SDT event]
>   sdt_libc:memory_arena_reuse                        [SDT event]
>   sdt_libc:memory_arena_reuse_free_list              [SDT event]
>   sdt_libc:memory_arena_reuse_wait                   [SDT event]
>   sdt_libc:memory_calloc_retry                       [SDT event]
>   sdt_libc:memory_heap_free                          [SDT event]
>   ...
>
> But none of them work:
>
>   Error:  No permissions to read /sys/kernel/debug/tracing/events/sdt_libc/longjmp
>   Hint:   Try 'sudo mount -o remount,mode=755 /sys/kernel/debug/tracing'
>
>   ...
>
>   Error:  File /sys/kernel/debug/tracing/events/sdt_libc/longjmp not found.
>   Hint:   Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
>
> What kind of patches are required for SDT probes to work?

Hi Ingo,

I suppose you are trying to record SDT events without probing it.
In that case, first put a probe on an event and then try to record
it. For example,

$ ./perf list | grep sdt_
  sdt_glib:main__after_prepare                       [SDT event]
  sdt_glib:main__before_dispatch                     [SDT event]
  ...

$ ./perf record -a -e sdt_glib:main__after_prepare
  event syntax error: 'sdt_glib:main__after_prepare'
                       \___ unknown tracepoint

  Error:  File /sys/kernel/debug/tracing/events/sdt_glib/main__after_prepare not found.
  Hint: Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
  ...

$ ./perf probe sdt_glib:main__after_prepare
  Added new events:
    sdt_glib:main__after_prepare (on %main__after_prepare in /usr/lib64/libglib-2.0.so.0.5000.2)
    sdt_glib:main__after_prepare_1 (on %main__after_prepare in /usr/lib64/libglib-2.0.so.0.5000.2)

  You can now use it in all perf tools, such as:

    perf record -e sdt_glib:main__after_prepare_1 -aR sleep 1

$ ./perf record -a -e sdt_glib:main__after_prepare
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.191 MB perf.data ]

-Ravi

[toc] | [next] | [standalone]

#1565657

FromIngo Molnar <mingo@kernel.org>
Date2017-01-24 09:30 +0100
Message-ID<t34Ej-1TK-37@gated-at.bofh.it>
In reply to#1565508
* Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> wrote:

> 
> 
> On Wednesday 14 December 2016 01:06 PM, Ingo Molnar wrote:
> > * Alexis Berlemont <alexis.berlemont@gmail.com> wrote:
> >
> >> Hi Masami,
> >>
> >> Many thanks for your mail.
> >>
> >> Here is another patch set which tries to fix the points you mentioned:
> >>
> >> * Skip the arguments containing a constant ($123); 
> >> * Review the code in charge of the register renaming (search for '%'
> >>   and parse it);
> >> * Minor changes (print the argument in case of error, skipping, check
> >>   the sdt arg type index);
> >>
> >> Many thanks,
> >>
> >> Alexis.
> >>
> >> Alexis Berlemont (2):
> >>   perf sdt: add scanning of sdt probles arguments
> >>   perf probe: add sdt probes arguments into the uprobe cmd string
> > I'd like to hijack this thread to report an SDT oddity - one of my boxen reports 
> > lots of SDT tracepoints in 'perf list':
> >
> >   mem:<addr>[/len][:access]                          [Hardware breakpoint]
> >
> >   sdt_libc:lll_lock_wait_private                     [SDT event]
> >   sdt_libc:longjmp                                   [SDT event]
> >   sdt_libc:longjmp_target                            [SDT event]
> >   sdt_libc:memory_arena_new                          [SDT event]
> >   sdt_libc:memory_arena_retry                        [SDT event]
> >   sdt_libc:memory_arena_reuse                        [SDT event]
> >   sdt_libc:memory_arena_reuse_free_list              [SDT event]
> >   sdt_libc:memory_arena_reuse_wait                   [SDT event]
> >   sdt_libc:memory_calloc_retry                       [SDT event]
> >   sdt_libc:memory_heap_free                          [SDT event]
> >   ...
> >
> > But none of them work:
> >
> >   Error:  No permissions to read /sys/kernel/debug/tracing/events/sdt_libc/longjmp
> >   Hint:   Try 'sudo mount -o remount,mode=755 /sys/kernel/debug/tracing'
> >
> >   ...
> >
> >   Error:  File /sys/kernel/debug/tracing/events/sdt_libc/longjmp not found.
> >   Hint:   Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
> >
> > What kind of patches are required for SDT probes to work?
> 
> Hi Ingo,
> 
> I suppose you are trying to record SDT events without probing it.
> In that case, first put a probe on an event and then try to record
> it. For example,


Well, I was mainly complaining about the misleading messages and flow of the 
tooling here. Could you please improve the messages so that if I use it like the 
way I reported it results in me trying the right approach?

Thanks,

	Ingo

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

#1565700

FromRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Date2017-01-24 09:40 +0100
Message-ID<t34NZ-1Xv-51@gated-at.bofh.it>
In reply to#1565657

On Tuesday 24 January 2017 01:52 PM, Ingo Molnar wrote:
> * Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> wrote:
>
>>
>> On Wednesday 14 December 2016 01:06 PM, Ingo Molnar wrote:
>>> * Alexis Berlemont <alexis.berlemont@gmail.com> wrote:
>>>
>>>> Hi Masami,
>>>>
>>>> Many thanks for your mail.
>>>>
>>>> Here is another patch set which tries to fix the points you mentioned:
>>>>
>>>> * Skip the arguments containing a constant ($123); 
>>>> * Review the code in charge of the register renaming (search for '%'
>>>>   and parse it);
>>>> * Minor changes (print the argument in case of error, skipping, check
>>>>   the sdt arg type index);
>>>>
>>>> Many thanks,
>>>>
>>>> Alexis.
>>>>
>>>> Alexis Berlemont (2):
>>>>   perf sdt: add scanning of sdt probles arguments
>>>>   perf probe: add sdt probes arguments into the uprobe cmd string
>>> I'd like to hijack this thread to report an SDT oddity - one of my boxen reports 
>>> lots of SDT tracepoints in 'perf list':
>>>
>>>   mem:<addr>[/len][:access]                          [Hardware breakpoint]
>>>
>>>   sdt_libc:lll_lock_wait_private                     [SDT event]
>>>   sdt_libc:longjmp                                   [SDT event]
>>>   sdt_libc:longjmp_target                            [SDT event]
>>>   sdt_libc:memory_arena_new                          [SDT event]
>>>   sdt_libc:memory_arena_retry                        [SDT event]
>>>   sdt_libc:memory_arena_reuse                        [SDT event]
>>>   sdt_libc:memory_arena_reuse_free_list              [SDT event]
>>>   sdt_libc:memory_arena_reuse_wait                   [SDT event]
>>>   sdt_libc:memory_calloc_retry                       [SDT event]
>>>   sdt_libc:memory_heap_free                          [SDT event]
>>>   ...
>>>
>>> But none of them work:
>>>
>>>   Error:  No permissions to read /sys/kernel/debug/tracing/events/sdt_libc/longjmp
>>>   Hint:   Try 'sudo mount -o remount,mode=755 /sys/kernel/debug/tracing'
>>>
>>>   ...
>>>
>>>   Error:  File /sys/kernel/debug/tracing/events/sdt_libc/longjmp not found.
>>>   Hint:   Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
>>>
>>> What kind of patches are required for SDT probes to work?
>> Hi Ingo,
>>
>> I suppose you are trying to record SDT events without probing it.
>> In that case, first put a probe on an event and then try to record
>> it. For example,
>
> Well, I was mainly complaining about the misleading messages and flow of the 
> tooling here. Could you please improve the messages so that if I use it like the 
> way I reported it results in me trying the right approach?

Right, message is misleading. Will prepare a patch for this.

Also it's little odd flow for sdt markers, to put a probe first and then
record it while other events can be recorded directly. There was a
patch by Hemant about directly recording SDT marker events. I
don't see any updates on that:

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1138183.html

-Ravi

> Thanks,
>
> 	Ingo
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web