Messages in this thread | | | Date | Tue, 11 Nov 2014 15:53:42 +0900 | From | Masami Hiramatsu <> | Subject | Re: [RFC] perf-cache command interface design |
| |
(2014/11/10 21:23), Arnaldo Carvalho de Melo wrote: > Em Mon, Nov 10, 2014 at 07:59:24PM +0900, Masami Hiramatsu escreveu: >> Hello, >> >> 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.
>> 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.
>> 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.
>> Query the probe definitions. >> perf cache --query [<GROUP>:]<EVENT>[@<PATH>][#<BUILDID>] > > Replace --query with --show?
OK.
Thank you,
> >> File Format >> =========== >> All the cache files are placed under ~/.debug/ by default. >> Elf caches are ~/.debug/path/to/file/bu/ildid/elf >> Symbols caches are ~/.debug/path/to/file/bu/ildid/syms >> Probes(and SDT) are ~/.debug/path/to/file/bu/ildid/probes >> And ~/.debug/path/to/file/bu/ildid/ is linked to ~/.debug/.buildid/bu/ildid >> Optionally, we can gzip the probes file. > > Ok! > >> This probe caches contain probe-definitions as following format. >> ---- >> #buildid:BUILDID >> #spec:SDT >> p:sdt_<PROVIDER>/<EVENT> PATH:OFFSET [ARGS] >> ... >> #spec:* $params >> p:probe_<GROUP>/<EVENT> _text+OFFSET [ARGS] >> ... >> ---- >> So the #spec: line gives the information what probe spec has been given. >> This will be used for updating. >> >> And all the "probe_" and "sdt_" prefix will be replaced by % in the command line, >> e.g. >> >> perf record -e %<PROVIDER>/<EVENT> -> this records sdt_PROVIDER/EVENT >> >> Thank you, >> >> -- >> Masami HIRAMATSU >> Software Platform Research Dept. Linux Technology Research Center >> Hitachi, Ltd., Yokohama Research Laboratory >> E-mail: masami.hiramatsu.pt@hitachi.com >> >
-- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |