[lkml]   [2014]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] perf-cache command interface design
(2014/11/11 22:10), Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 11, 2014 at 03:53:42PM +0900, Masami Hiramatsu escreveu:
>> (2014/11/10 21:23), Arnaldo Carvalho de Melo wrote:
>>> Em Mon, Nov 10, 2014 at 07:59:24PM +0900, Masami Hiramatsu escreveu:
>>>> Here is the second try for the probe-cache. This version simplifies
>>>> the synopsis, and unifies the SDT and probe caches.
>>>> Please give me your comments/ideas!
>>>> Command-line Synopsis
>>>> =====================
>>>> Add elf(or symbols) and probe-caches of SDT if exists in <FILES>
>>>> perf cache --add <FILES> [--probe <SPEC>] # for user programs
>>> Why the --probe above? Shouldn't this be just (if you are talking about
>>> ELF files only):
>>> perf cache --add <FILES>
>> Yes, for the elf and sdt cache, we don't need --probe.
>> Note that "[]" means optional. If we would like to add some probe cache,
>> we need a spec of probe definition.
> I understand that, its just that it looked superfluous at that specific
> place, where you are explaining how to add ELF files.
>>>> perf cache --kcore <FILE> [--probe <SPEC>] # for kcore ?
>>> Adrian, aren't kcore files easily identifiable as such and thus could be
>>> added as:
>>> perf cache --add <FILES>
>>>> perf cache --probe <SPEC> # for the current kernel
>>> Why do we need a --probe here? Don't they always start with a character
>>> that is seldomly used in ELF file names and thus we could get away with
>>> not requiring --probe?
>> This is only for adding the probe cache (not elf, nor sdt), which requires
>> a probe definition. Moreover, I'd like to unify the specification of the
>> probe definition with perf-probe. In that case, --probe is more natural.
> What I meant was, what is wrong with replacing:
> perf cache --probe <SPEC> # for the current kernel
> With:
> perf cache --add <PROBE-SPEC> # for the current kernel
> And have it figure out that what is being added is a probe and do the
> right thing?

As I've said previously, PROBE-SPEC can be same as FILES (imagine that a binary
file which has same name function in the kernel.)
Moreover, PROBE-SPEC requires the target binary(or kernel module) except for
kernel probes. In that case, anyway we need -x or -m options with file-path
for --add, that is very strange.


For me,

perf cache --add ./binary --probe '*'

looks more natural than

perf cache --add '*' -exec ./binary

since in other cases(sdt/elf), we'll just do

perf cache --add ./binary


>>>> Remove caches related to <FILES> or <BUILDIDS>
>>>> perf cache --remove <FILES>|<BUILDIDS>
>>>> Show all probe caches(including SDT) or buildids
>>>> perf cache --list [probe|buildid]
>>>> Delete existing probe-cache entries for kernel, <PATH> or/and <BUILDID>.
>>>> perf cache --probe-del [<GROUP>:]<EVENT>[@<PATH>][#<BUILDID>]
>>> Ditto, i.e. can't we just use:
>>> perf cache --remove [<GROUP>:]<EVENT>[@<PATH>][#<BUILDID>]
>>> And it figure out that this is a probe that is being removed?
>> In most cases, it may be OK, but it is also possible to cause unexpected
>> result when mis-typing. I think if <FILE> is always starting at '/', it
>> is easy to identify.
> We can keep the explicit switch (--probe-del) perhaps to resolve
> ambiguities, if they happen, but make it so that it is not strictly
> required for the common case.

OK, it'll take a longer time to remove, since we need to load all caches
to find matching entries of probe caches, but is feasible.

Thank you!

Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2014-11-12 17:01    [W:0.092 / U:1.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site