This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
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: Tue, 22 Jul 2014 14:30:05 +0900
- Subject: 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> <53CB349E dot 50609 at hitachi dot com> <53CD068B dot 7000504 at linux dot vnet dot ibm dot com>
(2014/07/21 21:24), Hemant Kumar wrote:
>
> On 07/20/2014 08:46 AM, Masami Hiramatsu wrote:
>> (2014/07/20 2:32), Hemant Kumar wrote:
>>>>> [SNIP]
>>>>> 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.
>
> Ok, I understand now.
>
>> 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
>
> Yeah, I agree with the above mentioned functions.
>
> So, according to this, if perf list sdt <file> can't find the SDT events
> for that file
> in the SDT cache, should it say "use perf sdt-cache --add <file> to add
> the SDT
> events for that file to the cache", or silently, should add that file's
> SDT events
> to SDT cache?
Hmm, it's a good question. Since the SDT events will be used as a normal
events, perf-record may NOT take an option of execfile in where SDT events are.
This means that if the given events are not cached, perf-record always fails.
Thus, I think we have 2 options, one is just removing "perf-list sdt <file>"
support, or another is "perf-list sdt <file>" silently caches the SDT in <file>.
IMHO, at the first version, we'd better just removes "perf-list sdt <file>"
support, since it is very simple model. And if someone asks supporting that,
we can add that afterwords as an enhancement. ;)
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com