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: Mon, 21 Jul 2014 17:54:43 +0530 [thread overview]
Message-ID: <53CD068B.7000504@linux.vnet.ibm.com> (raw)
In-Reply-To: <53CB349E.50609@hitachi.com>
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?
> And if perf list can't find sdt-cache, it would suggest to run
> perf sdt-cache --scan or run it silently. :)
>
> [...]
--
Thanks,
Hemant Kumar
next prev parent reply other threads:[~2014-07-21 12:24 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
2014-07-20 3:16 ` Masami Hiramatsu
2014-07-21 2:29 ` Namhyung Kim
2014-07-21 12:24 ` Hemant Kumar [this message]
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=53CD068B.7000504@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.