This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Re: [PATCH v2 0/3] perf/sdt : Support for SDT markers
- From: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: Hemant Kumar <hemant at linux dot vnet dot ibm dot com>
- Cc: linux-kernel at vger dot kernel dot org, srikar at linux dot vnet dot ibm dot com, peterz at infradead dot org, oleg at redhat dot com, hegdevasant at linux dot vnet dot ibm dot com, mingo at redhat dot com, anton at redhat dot com, systemtap at sourceware dot org, namhyung at kernel dot org, aravinda at linux dot vnet dot ibm dot com, penberg at iki dot fi
- Date: Sun, 20 Jul 2014 12:16:46 +0900
- Subject: Re: Re: [PATCH v2 0/3] perf/sdt : Support for SDT markers
- Authentication-results: sourceware.org; auth=none
- References: <20140717054826 dot 19995 dot 61782 dot stgit at hemant-fedora> <53C903B7 dot 6070905 at hitachi dot com> <53CAABCB dot 5080202 at linux dot vnet dot ibm dot com>
(2014/07/20 2:32), Hemant Kumar wrote:
>>> 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?
I think there may be some other cases, for example adding user local build
binary to the cache, or remove/update it locally. :)
And also, in user's mental model of perf-list, it doesn't take an "active"
action, that always does "passive" action. So adding such "active" scan option
will be more confusing.
But I also think it is OK that if the sdt is never scanned, the perf-list
automatically scans in background (without any option) or suggests user
to run "perf sdt-cache --scan". (it depends on how long time it may take)
To summarize it, I'd like to suggest adding below functions;
perf list sdt : shows all cached SDT events
perf list sdt <file> : shows SDT events in <file>
perf sdt-cache --scan/-s : scans all system binaries/libraries + added files
perf sdt-cache --add/-a <file(s)> : add SDT events in <file> to cache
perf sdt-cache --remove/-r <file(s)>: remove SDT events in <file> from cache
And if perf list can't find sdt-cache, it would suggest to run
perf sdt-cache --scan or run it silently. :)
What would you think about this?
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com