perf-annotate(1) ================ NAME ---- perf-annotate - Read perf.data (created by perf record) and display annotated code SYNOPSIS -------- [verse] 'perf annotate' [-i | --input=file] [symbol_name] DESCRIPTION ----------- This command reads the input file and displays an annotated version of the code. If the object file has debug symbols then the source code will be displayed alongside assembly code. If there is no debug info in the object, then annotated assembly is displayed. OPTIONS ------- -i:: --input=:: Input file name. (default: perf.data unless stdin is a fifo) -d:: --dsos=:: Only consider symbols in these dsos. -s:: --symbol=:: Symbol to annotate. -f:: --force:: Don't do ownership validation. -v:: --verbose:: Be more verbose. (Show symbol address, etc) -D:: --dump-raw-trace:: Dump raw trace in ASCII. -k:: --vmlinux=:: vmlinux pathname. -m:: --modules:: Load module symbols. WARNING: use only with -k and LIVE kernel. -l:: --print-line:: Print matching source lines (may be slow). -P:: --full-paths:: Don't shorten the displayed pathnames. --stdio:: Use the stdio interface. --stdio-color:: 'always', 'never' or 'auto', allowing configuring color output via the command line, in addition to via "color.ui" .perfconfig. Use '--stdio-color always' to generate color even when redirecting to a pipe or file. Using just '--stdio-color' is equivalent to using 'always'. --tui:: Use the TUI interface. Use of --tui requires a tty, if one is not present, as when piping to other commands, the stdio interface is used. This interfaces starts by centering on the line with more samples, TAB/UNTAB cycles through the lines with more samples. --gtk:: Use the GTK interface. -C:: --cpu:: Only report samples for the list of CPUs provided. Multiple CPUs can be provided as a comma-separated list with no space: 0,1. Ranges of CPUs are specified with -: 0-2. Default is to report samples on all CPUs. --asm-raw:: Show raw instruction encoding of assembly instructions. --source:: Interleave source code with assembly code. Enabled by default, disable with --no-source. --symfs=:: Look for files with symbols relative to this directory. -M:: --disassembler-style=:: Set disassembler style for objdump. --objdump=:: Path to objdump binary. --skip-missing:: Skip symbols that cannot be annotated. --group:: Show event group information together SEE ALSO -------- linkperf:perf-record[1], linkperf:perf-report[1] n value='grep'>log msg

path: root/tools/perf/Documentation/perf-data.txt

on value='3' selected='selected'>3

Age	Commit message (Expand)	Author	Files	Lines
space:
mode:

author	Steven Rostedt (VMware) <rostedt@goodmis.org>	2017-01-30 19:27:10 -0500
committer	Steven Rostedt (VMware) <rostedt@goodmis.org>	2017-01-31 09:13:49 -0500
commit	79c6f448c8b79c321e4a1f31f98194e4f6b6cae7 (patch)
tree	370efda701f03cccf21e02bb1fdd3b852547d75c /tools/lib/api/debug-internal.h
parent	0c744ea4f77d72b3dcebb7a8f2684633ec79be88 (diff)

tracing: Fix hwlat kthread migration

The hwlat tracer creates a kernel thread at start of the tracer. It is pinned to a single CPU and will move to the next CPU after each period of running. If the user modifies the migration thread's affinity, it will not change after that happens. The original code created the thread at the first instance it was called, but later was changed to destroy the thread after the tracer was finished, and would not be created until the next instance of the tracer was established. The code that initialized the affinity was only called on the initial instantiation of the tracer. After that, it was not initialized, and the previous affinity did not match the current newly created one, making it appear that the user modified the thread's affinity when it did not, and the thread failed to migrate again. Cc: stable@vger.kernel.org Fixes: 0330f7aa8ee6 ("tracing: Have hwlat trace migrate across tracing_cpumask CPUs") Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

Diffstat (limited to 'tools/lib/api/debug-internal.h')