Root/
1 | perf-record(1) |
2 | ============== |
3 | |
4 | NAME |
5 | ---- |
6 | perf-record - Run a command and record its profile into perf.data |
7 | |
8 | SYNOPSIS |
9 | -------- |
10 | [verse] |
11 | 'perf record' [-e <EVENT> | --event=EVENT] [-l] [-a] <command> |
12 | 'perf record' [-e <EVENT> | --event=EVENT] [-l] [-a] -- <command> [<options>] |
13 | |
14 | DESCRIPTION |
15 | ----------- |
16 | This command runs a command and gathers a performance counter profile |
17 | from it, into perf.data - without displaying anything. |
18 | |
19 | This file can then be inspected later on, using 'perf report'. |
20 | |
21 | |
22 | OPTIONS |
23 | ------- |
24 | <command>...:: |
25 | Any command you can specify in a shell. |
26 | |
27 | -e:: |
28 | --event=:: |
29 | Select the PMU event. Selection can be: |
30 | |
31 | - a symbolic event name (use 'perf list' to list all events) |
32 | |
33 | - a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a |
34 | hexadecimal event descriptor. |
35 | |
36 | - a hardware breakpoint event in the form of '\mem:addr[:access]' |
37 | where addr is the address in memory you want to break in. |
38 | Access is the memory access type (read, write, execute) it can |
39 | be passed as follows: '\mem:addr[:[r][w][x]]'. |
40 | If you want to profile read-write accesses in 0x1000, just set |
41 | 'mem:0x1000:rw'. |
42 | |
43 | --filter=<filter>:: |
44 | Event filter. |
45 | |
46 | -a:: |
47 | --all-cpus:: |
48 | System-wide collection from all CPUs. |
49 | |
50 | -l:: |
51 | Scale counter values. |
52 | |
53 | -p:: |
54 | --pid=:: |
55 | Record events on existing process ID. |
56 | |
57 | -t:: |
58 | --tid=:: |
59 | Record events on existing thread ID. |
60 | |
61 | -r:: |
62 | --realtime=:: |
63 | Collect data with this RT SCHED_FIFO priority. |
64 | -D:: |
65 | --no-delay:: |
66 | Collect data without buffering. |
67 | -A:: |
68 | --append:: |
69 | Append to the output file to do incremental profiling. |
70 | |
71 | -f:: |
72 | --force:: |
73 | Overwrite existing data file. (deprecated) |
74 | |
75 | -c:: |
76 | --count=:: |
77 | Event period to sample. |
78 | |
79 | -o:: |
80 | --output=:: |
81 | Output file name. |
82 | |
83 | -i:: |
84 | --no-inherit:: |
85 | Child tasks do not inherit counters. |
86 | -F:: |
87 | --freq=:: |
88 | Profile at this frequency. |
89 | |
90 | -m:: |
91 | --mmap-pages=:: |
92 | Number of mmap data pages. |
93 | |
94 | -g:: |
95 | --call-graph:: |
96 | Do call-graph (stack chain/backtrace) recording. |
97 | |
98 | -q:: |
99 | --quiet:: |
100 | Don't print any message, useful for scripting. |
101 | |
102 | -v:: |
103 | --verbose:: |
104 | Be more verbose (show counter open errors, etc). |
105 | |
106 | -s:: |
107 | --stat:: |
108 | Per thread counts. |
109 | |
110 | -d:: |
111 | --data:: |
112 | Sample addresses. |
113 | |
114 | -T:: |
115 | --timestamp:: |
116 | Sample timestamps. Use it with 'perf report -D' to see the timestamps, |
117 | for instance. |
118 | |
119 | -n:: |
120 | --no-samples:: |
121 | Don't sample. |
122 | |
123 | -R:: |
124 | --raw-samples:: |
125 | Collect raw sample records from all opened counters (default for tracepoint counters). |
126 | |
127 | -C:: |
128 | --cpu:: |
129 | Collect samples only on the list of CPUs provided. Multiple CPUs can be provided as a |
130 | comma-separated list with no space: 0,1. Ranges of CPUs are specified with -: 0-2. |
131 | In per-thread mode with inheritance mode on (default), samples are captured only when |
132 | the thread executes on the designated CPUs. Default is to monitor all CPUs. |
133 | |
134 | -N:: |
135 | --no-buildid-cache:: |
136 | Do not update the builid cache. This saves some overhead in situations |
137 | where the information in the perf.data file (which includes buildids) |
138 | is sufficient. |
139 | |
140 | -G name,...:: |
141 | --cgroup name,...:: |
142 | monitor only in the container (cgroup) called "name". This option is available only |
143 | in per-cpu mode. The cgroup filesystem must be mounted. All threads belonging to |
144 | container "name" are monitored when they run on the monitored CPUs. Multiple cgroups |
145 | can be provided. Each cgroup is applied to the corresponding event, i.e., first cgroup |
146 | to first event, second cgroup to second event and so on. It is possible to provide |
147 | an empty cgroup (monitor all the time) using, e.g., -G foo,,bar. Cgroups must have |
148 | corresponding events, i.e., they always refer to events defined earlier on the command |
149 | line. |
150 | |
151 | SEE ALSO |
152 | -------- |
153 | linkperf:perf-stat[1], linkperf:perf-list[1] |
154 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9