This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC] perf-cache command interface design
- From: Arnaldo Carvalho de Melo <acme at redhat dot com>
- To: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- Cc: Hemant Kumar <hemant at linux dot vnet dot ibm dot com>, Namhyung Kim <namhyung at kernel dot org>, 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, systemtap at sourceware dot org, aravinda at linux dot vnet dot ibm dot com, penberg at iki dot fi, brendan dot d dot gregg at gmail dot com, "yrl dot pp-manager dot tt at hitachi dot com" <yrl dot pp-manager dot tt at hitachi dot com>
- Date: Mon, 10 Nov 2014 10:23:21 -0200
- Subject: Re: [RFC] perf-cache command interface design
- Authentication-results: sourceware.org; auth=none
- References: <20141102105006 dot 21708 dot 28734 dot stgit at hemant-fedora> <20141102105557 dot 21708 dot 19032 dot stgit at hemant-fedora> <87lhnr5sbl dot fsf at sejong dot aot dot lge dot com> <54588905 dot 7040002 at linux dot vnet dot ibm dot com> <5458CD15 dot 4010101 at hitachi dot com> <874muew2hk dot fsf at sejong dot aot dot lge dot com> <5459E865 dot 6050207 at hitachi dot com> <545B1DDE dot 9000202 at linux dot vnet dot ibm dot com> <545C80F4 dot 4020905 at hitachi dot com> <54609A8C dot 4050308 at hitachi dot com>
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>
> 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?
> 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?
> Query the probe definitions.
> perf cache --query [<GROUP>:]<EVENT>[@<PATH>][#<BUILDID>]
Replace --query with --show?
> 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
>