All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hemant Kumar <hemant@linux.vnet.ibm.com>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: linux-kernel@vger.kernel.org, srikar@linux.vnet.ibm.com,
	peterz@infradead.org, oleg@redhat.com,
	hegdevasant@linux.vnet.ibm.com, mingo@redhat.com,
	anton@redhat.com, systemtap@sourceware.org, namhyung@kernel.org,
	aravinda@linux.vnet.ibm.com, penberg@iki.fi
Subject: Re: [PATCH v2 0/3] perf/sdt : Support for SDT markers
Date: Sat, 19 Jul 2014 23:02:59 +0530	[thread overview]
Message-ID: <53CAABCB.5080202@linux.vnet.ibm.com> (raw)
In-Reply-To: <53C903B7.6070905@hitachi.com>


On 07/18/2014 04:53 PM, Masami Hiramatsu wrote:
> Hi Hemant,
>
> (2014/07/17 14:53), Hemant Kumar wrote:
>> This patchset helps in listing dtrace style markers(SDT) present in user space
>> applications through perf.
>> Notes/markers are placed at important places by the
>> developers. They have a negligible overhead when not enabled.
>> We can enable them and probe at these places and find some important information
>> like the arguments' values, etc.
> Thanks for your work! This actually helps us a lot :)

Thanks a lot for the appreciation. :)

>
>> We have lots of applications which use SDT markers today, like:
>> Postgresql, MySql, Mozilla, Perl, Python, Java, Ruby, libvirt, QEMU, glib
>>
>> To add SDT markers into user applications:
>> We need to have this header sys/sdt.h present.
>> sys/sdt.h used is version 3.
>> If not present, install systemtap-sdt-devel package (for fedora-18).
>>
>> Please refer to the Documentation patch to see how the SDT markers are added into
>> a program.
>>
>> With this patchset,
>> - Use perf to list the markers in the app:
>> # perf list sdt ./user_app
>>
>> ./user_app :
>> %user_app:foo_start
>> %user_app:fun_start
>>
>> - Also, we can see the SDT markers present in our system in the usual binaries.
>> These usual binaries are libraries (dsos) listed by ldconfig --print-cache and some
>> binaries present in PATH environment variable.
>>
>> First, scan the binaries using :
>> # perf list sdt --scan
> At a glance, maybe we'd better have perf sdt-cache as like as perf buildid-cache
> for manage sdt information. what would you think?
>

I agree with you having perf sdt-cache similar to perf buildid-cache.
But I think if the functionality of perf sdt-cache is only to build the 
cache, then we can
go with the perf list sdt --scan. Since, "perf list sdt" is used for 
other purposes too, it
should be less confusing for the users to just add another option 
(--scan) to create/modify
the cache. What do you suggest?

>> Creating a cache of SDT markers...
>> perf sdt cache created!
>>   Use : "perf list sdt"
>>   to see the SDT markers
>>
>> After the sdt cache file is created, use perf list to view the markers :
>> # perf list sdt
>>
>> %rtld : init_start
>> %rtld : init_complete
>> %rtld : map_failed
>> %rtld : map_start
>> %rtld : lll_futex_wake
>> ...
>> ...
>> %libgcc : unwind
>> %libvirt : rpc_server_client_auth_allow
>> %libvirt : rpc_server_client_auth_fail
>> %libvirt : rpc_server_client_auth_deny
> Looks good :)
> It seems very useful for perf users.
>
> Thank you,

Thanks a lot for going through this.

-- 
Thanks,
Hemant Kumar


  reply	other threads:[~2014-07-19 17:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-17  5:53 [PATCH v2 0/3] perf/sdt : Support for SDT markers Hemant Kumar
2014-07-17  5:55 ` [PATCH v2 1/3] perf/sdt : Listing of SDT markers by perf Hemant Kumar
2014-07-18 17:50   ` Andi Kleen
2014-07-20  3:17     ` Masami Hiramatsu
2014-07-21  2:38     ` Namhyung Kim
2014-07-21  9:40       ` Hemant Kumar
2014-07-22 11:53     ` Hemant Kumar
2014-07-21  3:01   ` Namhyung Kim
2014-07-22 11:33     ` Hemant Kumar
2014-07-17  5:56 ` [PATCH v2 2/3] perf/sdt: Listing SDT markers for a single file Hemant Kumar
2014-07-17  5:56 ` [PATCH v2 3/3] perf/sdt: Documentation Hemant Kumar
2014-07-18 11:23 ` [PATCH v2 0/3] perf/sdt : Support for SDT markers Masami Hiramatsu
2014-07-19 17:32   ` Hemant Kumar [this message]
2014-07-20  3:16     ` Masami Hiramatsu
2014-07-21  2:29       ` Namhyung Kim
2014-07-21 12:24       ` Hemant Kumar
2014-07-22  5:30         ` Masami Hiramatsu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53CAABCB.5080202@linux.vnet.ibm.com \
    --to=hemant@linux.vnet.ibm.com \
    --cc=anton@redhat.com \
    --cc=aravinda@linux.vnet.ibm.com \
    --cc=hegdevasant@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=oleg@redhat.com \
    --cc=penberg@iki.fi \
    --cc=peterz@infradead.org \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.