diff options
Diffstat (limited to 'documentation/profile-manual/usage.rst')
-rw-r--r-- | documentation/profile-manual/usage.rst | 24 |
1 files changed, 12 insertions, 12 deletions
diff --git a/documentation/profile-manual/usage.rst b/documentation/profile-manual/usage.rst index 3c9321f09c..a190e743cd 100644 --- a/documentation/profile-manual/usage.rst +++ b/documentation/profile-manual/usage.rst | |||
@@ -17,7 +17,7 @@ The 'perf' tool is the profiling and tracing tool that comes bundled | |||
17 | with the Linux kernel. | 17 | with the Linux kernel. |
18 | 18 | ||
19 | Don't let the fact that it's part of the kernel fool you into thinking | 19 | Don't let the fact that it's part of the kernel fool you into thinking |
20 | that it's only for tracing and profiling the kernel - you can indeed use | 20 | that it's only for tracing and profiling the kernel --- you can indeed use |
21 | it to trace and profile just the kernel, but you can also use it to | 21 | it to trace and profile just the kernel, but you can also use it to |
22 | profile specific applications separately (with or without kernel | 22 | profile specific applications separately (with or without kernel |
23 | context), and you can also use it to trace and profile the kernel and | 23 | context), and you can also use it to trace and profile the kernel and |
@@ -176,7 +176,7 @@ interactive text-based UI (or simply as text if we specify ``--stdio`` to | |||
176 | 176 | ||
177 | As our first attempt at profiling this workload, we'll simply run 'perf | 177 | As our first attempt at profiling this workload, we'll simply run 'perf |
178 | record', handing it the workload we want to profile (everything after | 178 | record', handing it the workload we want to profile (everything after |
179 | 'perf record' and any perf options we hand it - here none - will be | 179 | 'perf record' and any perf options we hand it --- here none, will be |
180 | executed in a new shell). perf collects samples until the process exits | 180 | executed in a new shell). perf collects samples until the process exits |
181 | and records them in a file named 'perf.data' in the current working | 181 | and records them in a file named 'perf.data' in the current working |
182 | directory. :: | 182 | directory. :: |
@@ -202,7 +202,7 @@ The above screenshot displays a 'flat' profile, one entry for each | |||
202 | 'bucket' corresponding to the functions that were profiled during the | 202 | 'bucket' corresponding to the functions that were profiled during the |
203 | profiling run, ordered from the most popular to the least (perf has | 203 | profiling run, ordered from the most popular to the least (perf has |
204 | options to sort in various orders and keys as well as display entries | 204 | options to sort in various orders and keys as well as display entries |
205 | only above a certain threshold and so on - see the perf documentation | 205 | only above a certain threshold and so on --- see the perf documentation |
206 | for details). Note that this includes both userspace functions (entries | 206 | for details). Note that this includes both userspace functions (entries |
207 | containing a [.]) and kernel functions accounted to the process (entries | 207 | containing a [.]) and kernel functions accounted to the process (entries |
208 | containing a [k]). (perf has command-line modifiers that can be used to | 208 | containing a [k]). (perf has command-line modifiers that can be used to |
@@ -597,7 +597,7 @@ and tell perf to do a profile using it as the sampling event:: | |||
597 | The screenshot above shows the results of running a profile using | 597 | The screenshot above shows the results of running a profile using |
598 | sched:sched_switch tracepoint, which shows the relative costs of various | 598 | sched:sched_switch tracepoint, which shows the relative costs of various |
599 | paths to sched_wakeup (note that sched_wakeup is the name of the | 599 | paths to sched_wakeup (note that sched_wakeup is the name of the |
600 | tracepoint - it's actually defined just inside ttwu_do_wakeup(), which | 600 | tracepoint --- it's actually defined just inside ttwu_do_wakeup(), which |
601 | accounts for the function name actually displayed in the profile: | 601 | accounts for the function name actually displayed in the profile: |
602 | 602 | ||
603 | .. code-block:: c | 603 | .. code-block:: c |
@@ -866,7 +866,7 @@ System-Wide Tracing and Profiling | |||
866 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 866 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
867 | 867 | ||
868 | The examples so far have focused on tracing a particular program or | 868 | The examples so far have focused on tracing a particular program or |
869 | workload - in other words, every profiling run has specified the program | 869 | workload --- in other words, every profiling run has specified the program |
870 | to profile in the command-line e.g. 'perf record wget ...'. | 870 | to profile in the command-line e.g. 'perf record wget ...'. |
871 | 871 | ||
872 | It's also possible, and more interesting in many cases, to run a | 872 | It's also possible, and more interesting in many cases, to run a |
@@ -950,7 +950,7 @@ Filtering | |||
950 | Notice that there are a lot of events that don't really have anything to | 950 | Notice that there are a lot of events that don't really have anything to |
951 | do with what we're interested in, namely events that schedule 'perf' | 951 | do with what we're interested in, namely events that schedule 'perf' |
952 | itself in and out or that wake perf up. We can get rid of those by using | 952 | itself in and out or that wake perf up. We can get rid of those by using |
953 | the '--filter' option - for each event we specify using -e, we can add a | 953 | the '--filter' option --- for each event we specify using -e, we can add a |
954 | --filter after that to filter out trace events that contain fields with | 954 | --filter after that to filter out trace events that contain fields with |
955 | specific values:: | 955 | specific values:: |
956 | 956 | ||
@@ -1120,7 +1120,7 @@ callgraphs from starting a few programs during those 30 seconds: | |||
1120 | .. admonition:: Tying it Together | 1120 | .. admonition:: Tying it Together |
1121 | 1121 | ||
1122 | The trace events subsystem accommodate static and dynamic tracepoints | 1122 | The trace events subsystem accommodate static and dynamic tracepoints |
1123 | in exactly the same way - there's no difference as far as the | 1123 | in exactly the same way --- there's no difference as far as the |
1124 | infrastructure is concerned. See the ftrace section for more details | 1124 | infrastructure is concerned. See the ftrace section for more details |
1125 | on the trace event subsystem. | 1125 | on the trace event subsystem. |
1126 | 1126 | ||
@@ -1186,7 +1186,7 @@ For this section, we'll assume you've already performed the basic setup | |||
1186 | outlined in the ":ref:`profile-manual/intro:General Setup`" section. | 1186 | outlined in the ":ref:`profile-manual/intro:General Setup`" section. |
1187 | 1187 | ||
1188 | ftrace, trace-cmd, and kernelshark run on the target system, and are | 1188 | ftrace, trace-cmd, and kernelshark run on the target system, and are |
1189 | ready to go out-of-the-box - no additional setup is necessary. For the | 1189 | ready to go out-of-the-box --- no additional setup is necessary. For the |
1190 | rest of this section we assume you've ssh'ed to the host and will be | 1190 | rest of this section we assume you've ssh'ed to the host and will be |
1191 | running ftrace on the target. kernelshark is a GUI application and if | 1191 | running ftrace on the target. kernelshark is a GUI application and if |
1192 | you use the '-X' option to ssh you can have the kernelshark GUI run on | 1192 | you use the '-X' option to ssh you can have the kernelshark GUI run on |
@@ -1306,7 +1306,7 @@ great way to learn about how the kernel code works in a dynamic sense. | |||
1306 | ftrace:function tracepoint. | 1306 | ftrace:function tracepoint. |
1307 | 1307 | ||
1308 | It is a little more difficult to follow the call chains than it needs to | 1308 | It is a little more difficult to follow the call chains than it needs to |
1309 | be - luckily there's a variant of the function tracer that displays the | 1309 | be --- luckily there's a variant of the function tracer that displays the |
1310 | callchains explicitly, called the 'function_graph' tracer:: | 1310 | callchains explicitly, called the 'function_graph' tracer:: |
1311 | 1311 | ||
1312 | root@sugarbay:/sys/kernel/debug/tracing# echo function_graph > current_tracer | 1312 | root@sugarbay:/sys/kernel/debug/tracing# echo function_graph > current_tracer |
@@ -2116,7 +2116,7 @@ You can now view the trace in text form on the target:: | |||
2116 | . | 2116 | . |
2117 | 2117 | ||
2118 | You can now safely destroy the trace | 2118 | You can now safely destroy the trace |
2119 | session (note that this doesn't delete the trace - it's still there in | 2119 | session (note that this doesn't delete the trace --- it's still there in |
2120 | ~/lttng-traces):: | 2120 | ~/lttng-traces):: |
2121 | 2121 | ||
2122 | root@crownbay:~# lttng destroy | 2122 | root@crownbay:~# lttng destroy |
@@ -2200,7 +2200,7 @@ You can now view the trace in text form on the target:: | |||
2200 | . | 2200 | . |
2201 | 2201 | ||
2202 | You can now safely destroy the trace session (note that this doesn't delete the | 2202 | You can now safely destroy the trace session (note that this doesn't delete the |
2203 | trace - it's still there in ~/lttng-traces):: | 2203 | trace --- it's still there in ~/lttng-traces):: |
2204 | 2204 | ||
2205 | root@crownbay:~# lttng destroy | 2205 | root@crownbay:~# lttng destroy |
2206 | Session auto-20190303-021943 destroyed at /home/root | 2206 | Session auto-20190303-021943 destroyed at /home/root |
@@ -2536,7 +2536,7 @@ Execute the workload you're interested in:: | |||
2536 | root@crownbay:/sys/kernel/debug/tracing# cat /media/sdc/testfile.txt | 2536 | root@crownbay:/sys/kernel/debug/tracing# cat /media/sdc/testfile.txt |
2537 | 2537 | ||
2538 | And look at the output (note here that we're using 'trace_pipe' instead of | 2538 | And look at the output (note here that we're using 'trace_pipe' instead of |
2539 | trace to capture this trace - this allows us to wait around on the pipe | 2539 | trace to capture this trace --- this allows us to wait around on the pipe |
2540 | for data to appear):: | 2540 | for data to appear):: |
2541 | 2541 | ||
2542 | root@crownbay:/sys/kernel/debug/tracing# cat trace_pipe | 2542 | root@crownbay:/sys/kernel/debug/tracing# cat trace_pipe |