profile-manual: Edits from Robert P. J. Day

If someone wants to check this over, make sure I didn't make
any silly changes.

(From yocto-docs rev: d1dd154740ffb9c858a66cab80486a4d684131da)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Robert P. J. Day 2013-11-15 08:52:26 -08:00 committed by Richard Purdie
parent ac3f5a3e78
commit a70b2f2a9c
1 changed files with 28 additions and 26 deletions

View File

@ -1377,7 +1377,7 @@
the /tracing directory of the mounted debugfs filesystem
(Yocto follows the standard convention and mounts it
at /sys/kernel/debug). Here's a listing of all the files
found in /sys/kernel/debug/tracing on a Yocto system.:
found in /sys/kernel/debug/tracing on a Yocto system:
<literallayout class='monospaced'>
root@sugarbay:/sys/kernel/debug/tracing# ls
README kprobe_events trace
@ -1634,7 +1634,7 @@
Also notice that there are various annotations on the left
hand side of the display. For example if the total time it
took for a given function to execute is above a certain
threshold, and exclamation point or plus sign appears on the
threshold, an exclamation point or plus sign appears on the
left hand side. Please see the ftrace documentation for
details on all these fields.
</para>
@ -1842,7 +1842,7 @@
</literallayout>
You can enable any number of events or complete subsystems
(by using the 'enable' file in the subsystem directory) and
get am arbitrarily fine-grained idea of what's going on in the
get an arbitrarily fine-grained idea of what's going on in the
system by enabling as many of the appropriate tracepoints
as applicable.
</para>
@ -1878,14 +1878,14 @@
in /sys/kernel/debug/tracing, allowing users to specify
specific particular events within the
/sys/kernel/debug/tracing/events/ subdirectory and to collect
traces and avoiding having to deal with those details directly.
traces and avoid having to deal with those details directly.
</para>
<para>
As yet another layer on top of that, kernelshark provides a GUI
that allows users to start and stop traces and specify sets
of events using an intuitive interface, and view the
output as both trace events and as a per-cpu graphical
output as both trace events and as a per-CPU graphical
display. It directly uses 'trace-cmd' as the plumbing
that accomplishes all that underneath the covers (and
actually displays the trace-cmd command it uses, as we'll see).
@ -1896,13 +1896,13 @@
<literallayout class='monospaced'>
root@sugarbay:~# kernelshark
</literallayout>
The bring up the 'Capture' dialog by choosing from the
Then bring up the 'Capture' dialog by choosing from the
kernelshark menu:
<literallayout class='monospaced'>
Capture | Record
</literallayout>
That will display the following dialog, which allows you to
choose on or more events (or even one or more complete
choose one or more events (or even one or more complete
subsystems) to trace:
</para>
@ -1911,7 +1911,7 @@
</para>
<para>
Note that these are exactly the same set of events described
Note that these are exactly the same sets of events described
in the previous trace events subsystem section, and in fact
is where trace-cmd gets them for kernelshark.
</para>
@ -1980,13 +1980,15 @@
<literallayout class='monospaced'>
Documentation/trace/events.txt
</literallayout>
There are a nice series of articles on using
There is a nice series of articles on using
ftrace and trace-cmd at LWN:
<itemizedlist>
<listitem><para><ulink url='http://lwn.net/Articles/365835/'>Debugging the kernel using Ftrace - part 1</ulink>
</para></listitem>
<listitem><para><ulink url='http://lwn.net/Articles/366796/'>Debugging the kernel using Ftrace - part 2</ulink>
</para></listitem>
<listitem><para><ulink url='http://lwn.net/Articles/370423/'>Secrets of the Ftrace function tracer</ulink>
</para></listitem>
<listitem><para><ulink url='https://lwn.net/Articles/410200/'>trace-cmd: A front-end for Ftrace</ulink>
</para></listitem>
</itemizedlist>
@ -2022,7 +2024,7 @@
<ulink url='http://sourceware.org/systemtap/tutorial/'>SystemTap tutorial</ulink>
simply prints a line every time any process on the system open()s
a file. For each line, it prints the executable name of the
program that opened the file, along with its pid, and the name
program that opened the file, along with its PID, and the name
of the file it opened (or tried to open), which it extracts
from the open syscall's argstr.
<literallayout class='monospaced'>
@ -2099,11 +2101,11 @@
<note>
SystemTap, which uses 'crosstap', assumes you can establish an
ssh connection to the remote target.
Please refer to crosstap wiki page for details on verifying
Please refer to the crosstap wiki page for details on verifying
ssh connections at
<ulink url='https://wiki.yoctoproject.org/wiki/Tracing_and_Profiling#systemtap'></ulink>.
Also, the ability to ssh into the target system is not enabled
by default in -minimal images.
by default in *-minimal images.
</note>
<literallayout class='monospaced'>
$ crosstap root@192.168.1.88 trace_open.stp
@ -2201,7 +2203,7 @@
<para>
If everything worked as planned, you should see something
like this (enter the password when prompted, or press enter
if its set up to use no password):
if it's set up to use no password):
<literallayout class='monospaced'>
$ crosstap root@192.168.7.2 trace_open.stp
root@192.168.7.2's password:
@ -2246,7 +2248,7 @@
</para>
<para>
For the the section that deals with oprofile from the command-line,
For the section that deals with running oprofile from the command-line,
we assume you've ssh'ed to the host and will be running
oprofile on the target.
</para>
@ -2266,7 +2268,7 @@
Oprofile as configured in Yocto is a system-wide profiler
(i.e. the version in Yocto doesn't yet make use of the
perf_events interface which would allow it to profile
specific processes and workloads). It's relies on hardware
specific processes and workloads). It relies on hardware
counter support in the hardware (but can fall back to a
timer-based mode), which means that it doesn't take
advantage of tracepoints or other event sources for example.
@ -2287,8 +2289,8 @@
<para>
The oprofile daemon should already be running, but before
you start profiling, you may need to change some settings
and some of these settings may require the daemon not
be running. One of these settings is the path the the
and some of these settings may require the daemon to not
be running. One of these settings is the path to the
vmlinux file, which you'll want to set using the --vmlinux
option if you want the kernel profiled:
<literallayout class='monospaced'>
@ -2319,7 +2321,7 @@
Using log file /var/lib/oprofile/samples/oprofiled.log
Daemon started.
</literallayout>
If we get the status again we now see our updated settings:
If we check the status again we now see our updated settings:
<literallayout class='monospaced'>
root@crownbay:~# opcontrol --status
Daemon paused: pid 1649
@ -2328,7 +2330,7 @@
Image filter: none
Call-graph depth: 6
</literallayout>
We're now in a position to run a profile. For that we used
We're now in a position to run a profile. For that we use
'opcontrol --start':
<literallayout class='monospaced'>
root@crownbay:~# opcontrol --start
@ -2340,10 +2342,10 @@
Connecting to downloads.yoctoproject.org (140.211.169.59:80)
linux-2.6.19.2.tar.b 100% |*******************************| 41727k 0:00:00 ETA
</literallayout>
To stop the profile we use 'opcontrol --shudown', which not
To stop the profile we use 'opcontrol --shutdown', which not
only stops the profile but shuts down the daemon as well:
<literallayout class='monospaced'>
root@crownbay:~# opcontrol --start
root@crownbay:~# opcontrol --shutdown
Stopping profiling.
Killing daemon.
</literallayout>
@ -2902,7 +2904,7 @@
<para>
Once you've applied the above commits and built and booted your
image (you need to build the core-image-sato-sdk image or the
image (you need to build the core-image-sato-sdk image or use one of the
other methods described in the General Setup section), you're
ready to start tracing.
</para>
@ -2911,7 +2913,7 @@
<title>Collecting and viewing a trace on the target (inside a shell)</title>
<para>
First, from the target, ssh to the target:
First, from the host, ssh to the target:
<literallayout class='monospaced'>
$ ssh -l root 192.168.1.47
The authenticity of host '192.168.1.47 (192.168.1.47)' can't be established.
@ -3012,7 +3014,7 @@
<title>Collecting and viewing a userspace trace on the target (inside a shell)</title>
<para>
For lttng userspace tracing, you need to have a properly
For LTTng userspace tracing, you need to have a properly
instrumented userspace program. For this example, we'll use
the 'hello' test program generated by the lttng-ust build.
</para>
@ -3034,7 +3036,7 @@
</para>
<para>
First, from the target, ssh to the target:
First, from the host, ssh to the target:
<literallayout class='monospaced'>
$ ssh -l root 192.168.1.47
The authenticity of host '192.168.1.47 (192.168.1.47)' can't be established.
@ -3600,7 +3602,7 @@
It's also possible to trace block I/O using only
<link linkend='the-trace-events-subsystem'>trace events subsystem</link>,
which can be useful for casual tracing
if you don't want bother dealing with the userspace tools.
if you don't want to bother dealing with the userspace tools.
</para>
<para>