lkml.org 
[lkml]   [2016]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] perf/sdt: Directly record cached SDT events
On Fri, Apr 29, 2016 at 6:40 AM, Hemant Kumar <hemant@linux.vnet.ibm.com> wrote:
> This patch adds support for directly recording SDT events which are
> present in the probe cache. This patch is based on current SDT
> enablement patchset (v5) by Masami :
> https://lkml.org/lkml/2016/4/27/828
> and it implements two points in the TODO list mentioned in the
> cover note :
> "- (perf record) Support SDT event recording directly"
> "- (perf record) Try to unregister SDT events after record."
>
> Without this patch, we could probe into SDT events using
> "perf probe" and "perf record". With this patch, we can probe
> the SDT events directly using "perf record".
>
> For example :
>
> # perf list sdt // List the SDT events
> ...
> sdt_mysql:update__row__done [SDT event]
> sdt_mysql:update__row__start [SDT event]
> sdt_mysql:update__start [SDT event]
> sdt_python:function__entry [SDT event]
> sdt_python:function__return [SDT event]
> sdt_test:marker1 [SDT event]
> sdt_test:marker2 [SDT event]
> ...
>
> # perf record -e %sdt_test:marker1 -e %sdt_test:marker2 -a

Why do we need the '%'? Can't the "sdt_" prefix be sufficient? ie:

# perf record -e sdt_test:marker1 -e sdt_test:marker2 -a

I find it a bit weird to define it using %sdt_, but then use it using
sdt_. I'd also be inclined to use it for probe creation, ie:

# perf probe -x /lib/libc-2.17.so sdt_libc:lll_lock_wait_private

That way, the user only learns one way to specify the probe, with the
sdt_ prefix. It's fine if % existed too, but optional.

> ^C[ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 2.087 MB perf.data (22 samples) ]
>
> # perf script
> test_sdt 29230 [002] 405550.548017: sdt_test:marker1: (400534)
> test_sdt 29230 [002] 405550.548064: sdt_test:marker2: (40053f)
> test_sdt 29231 [002] 405550.962806: sdt_test:marker1: (400534)
> test_sdt 29231 [002] 405550.962841: sdt_test:marker2: (40053f)
> test_sdt 29232 [001] 405551.379327: sdt_test:marker1: (400534)
> ...
>
> After invoking "perf record", behind the scenes, it checks whether the
> event specified is an SDT event using the flag '%'. After that, it
> does a lookup of the probe cache to find out the SDT event. If its not
> present, it throws an error. Otherwise, it goes on and writes the event
> into the uprobe_events file and sets up the probe event, trace events,
> etc and starts recording. It also maintains a list of the event names
> that were written to uprobe_events file. After finishing the record
> session, it removes the events from the uprobe_events file using the
> maintained name list.

Does this support semaphore SDT probes (is-enabled)? Those need the
semaphore incremented when enabled, then decremented when disabled.

Brendan

\
 
 \ /
  Last update: 2016-05-02 20:41    [W:0.517 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site