sysmo-bts
/
generic-poky
9
0
Fork 0
Code Pull Requests Releases Activity

profile-manual: Fixed the "Tying it Together" side-lights. 

Took them out of the colored Note format and replaced with
a simple line box to set them apart.

(From yocto-docs rev: 5efb84d3860d87f64371b718967ab33f47a3a4db)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark 2013-01-21 16:15:27 -06:00 committed by Richard Purdie
parent f3cb977699
commit b4b1dc1dd6
2 changed files with 39 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
documentation/profile-manual/profile-manual-arch.xml
View File

@ -32,12 +32,12 @@
</itemizedlist> </itemizedlist>
</para> </para>
<note> <informalexample>
Tying It Together: Rather than enumerating here how each tool makes use of <emphasis>Tying it Together:</emphasis> Rather than enumerating here how each tool makes use of
these common mechanisms, textboxes like this will make note of the these common mechanisms, textboxes like this will make note of the
specific usages in each tool as they come up in the course specific usages in each tool as they come up in the course
of the text. of the text.
</note> </informalexample>
</section> </section>
</chapter> </chapter>
<!-- <!--

72
documentation/profile-manual/profile-manual-usage.xml
View File

@ -605,13 +605,13 @@
</literallayout> </literallayout>
</para> </para>
<note> <informalexample>
Tying It Together: These are exactly the same set of events defined <emphasis>Tying it Together:</emphasis> These are exactly the same set of events defined
by the trace event subsystem and exposed by by the trace event subsystem and exposed by
ftrace/tracecmd/kernelshark as files in ftrace/tracecmd/kernelshark as files in
/sys/kernel/debug/tracing/events, by SystemTap as /sys/kernel/debug/tracing/events, by SystemTap as
kernel.trace("tracepoint_name") and (partially) accessed by LTTng. kernel.trace("tracepoint_name") and (partially) accessed by LTTng.
</note> </informalexample>
<para> <para>
Only a subset of these would be of interest to us when looking at Only a subset of these would be of interest to us when looking at
@ -836,8 +836,8 @@
bindings, one for Python and one for Perl. bindings, one for Python and one for Perl.
</para> </para>
<note> <informalexample>
Tying It Together: Language bindings for manipulating and <emphasis>Tying it Together:</emphasis> Language bindings for manipulating and
aggregating trace data are of course not a new aggregating trace data are of course not a new
idea. One of the first projects to do this was IBM's DProbes idea. One of the first projects to do this was IBM's DProbes
dpcc compiler, an ANSI C compiler which targeted a low-level dpcc compiler, an ANSI C compiler which targeted a low-level
@ -849,7 +849,7 @@
in-kernel interpreter, created an elaborate compiler-based in-kernel interpreter, created an elaborate compiler-based
machinery to translate its language into kernel modules written machinery to translate its language into kernel modules written
in C. in C.
</note> </informalexample>
<para> <para>
Now that we have the trace data in perf.data, we can use Now that we have the trace data in perf.data, we can use
@ -1132,15 +1132,15 @@
how to use filters, it's close enough. how to use filters, it's close enough.
</para> </para>
<note> <informalexample>
Tying It Together: These are exactly the same set of event <emphasis>Tying it Together:</emphasis> These are exactly the same set of event
filters defined by the trace event subsystem. See the filters defined by the trace event subsystem. See the
ftrace/tracecmd/kernelshark section for more discussion about ftrace/tracecmd/kernelshark section for more discussion about
these event filters. these event filters.
</note> </informalexample>
<note> <informalexample>
Tying It Together: These event filters are implemented by a <emphasis>Tying it Together:</emphasis> These event filters are implemented by a
special-purpose pseudo-interpreter in the kernel and are an special-purpose pseudo-interpreter in the kernel and are an
integral and indispensable part of the perf design as it integral and indispensable part of the perf design as it
relates to tracing. kernel-based event filters provide a relates to tracing. kernel-based event filters provide a
@ -1161,7 +1161,7 @@
application is causing buffer I/O overruns, it probably application is causing buffer I/O overruns, it probably
means that you aren't taking enough advantage of the means that you aren't taking enough advantage of the
kernel filtering engine. kernel filtering engine.
</note> </informalexample>
</section> </section>
</section> </section>
@ -1274,18 +1274,18 @@
<imagedata fileref="figures/perf-probe-do_fork-profile.png" width="6in" depth="7in" align="center" scalefit="1" /> <imagedata fileref="figures/perf-probe-do_fork-profile.png" width="6in" depth="7in" align="center" scalefit="1" />
</para> </para>
<note> <informalexample>
Tying It Together: The trace events subsystem accomodate static <emphasis>Tying it Together:</emphasis> The trace events subsystem accomodate static
and dynamic tracepoints in exactly the same way - there's no and dynamic tracepoints in exactly the same way - there's no
difference as far as the infrastructure is concerned. See the difference as far as the infrastructure is concerned. See the
ftrace section for more details on the trace event subsystem. ftrace section for more details on the trace event subsystem.
</note> </informalexample>
<note> <informalexample>
Tying It Together: Dynamic tracepoints are implemented under the <emphasis>Tying it Together:</emphasis> Dynamic tracepoints are implemented under the
covers by kprobes and uprobes. kprobes and uprobes are also used covers by kprobes and uprobes. kprobes and uprobes are also used
by and in fact are the main focus of SystemTap. by and in fact are the main focus of SystemTap.
</note> </informalexample>
</section> </section>
</section> </section>
@ -1496,10 +1496,10 @@
code works in a dynamic sense. code works in a dynamic sense.
</para> </para>
<note> <informalexample>
Tying It Together: The ftrace function tracer is also <emphasis>Tying it Together:</emphasis> The ftrace function tracer is also
available from within perf, as the ftrace:function tracepoint. available from within perf, as the ftrace:function tracepoint.
</note> </informalexample>
<para> <para>
It is a little more difficult to follow the call chains than It is a little more difficult to follow the call chains than
@ -1852,21 +1852,21 @@
including trace-cmd and kernelshark in the next section. including trace-cmd and kernelshark in the next section.
</para> </para>
<note> <informalexample>
Tying It Together: These tracepoints and their representation <emphasis>Tying it Together:</emphasis> These tracepoints and their representation
are used not only by ftrace, but by many of the other tools are used not only by ftrace, but by many of the other tools
covered in this document and they form a central point of covered in this document and they form a central point of
integration for the various tracers available in Linux. integration for the various tracers available in Linux.
They form a central part of the instrumentation for the They form a central part of the instrumentation for the
following tools: perf, lttng, ftrace, blktrace and SystemTap following tools: perf, lttng, ftrace, blktrace and SystemTap
</note> </informalexample>
<note> <informalexample>
Tying It Together: Eventually all the special-purpose tracers <emphasis>Tying it Together:</emphasis> Eventually all the special-purpose tracers
currently available in /sys/kernel/debug/tracing will be currently available in /sys/kernel/debug/tracing will be
removed and replaced with equivalent tracers based on the removed and replaced with equivalent tracers based on the
'trace events' subsystem. 'trace events' subsystem.
</note> </informalexample>
</section> </section>
<section id='trace-cmd-kernelshark'> <section id='trace-cmd-kernelshark'>
@ -2731,14 +2731,14 @@
<imagedata fileref="figures/oprofileui-busybox.png" width="6in" depth="7in" align="center" scalefit="1" /> <imagedata fileref="figures/oprofileui-busybox.png" width="6in" depth="7in" align="center" scalefit="1" />
</para> </para>
<note> <informalexample>
Tying It Together: oprofile does have build options to enable <emphasis>Tying it Together:</emphasis> oprofile does have build options to enable
use of the perf_event subsystem and benefit from the perf_event use of the perf_event subsystem and benefit from the perf_event
infrastructure by adding support for something other than infrastructure by adding support for something other than
system-wide profiling i.e. per-process or workload profiling, system-wide profiling i.e. per-process or workload profiling,
but the version in danny doesn't yet take advantage of but the version in danny doesn't yet take advantage of
those capabilities. those capabilities.
</note> </informalexample>
</section> </section>
<section id='oprofile-documentation'> <section id='oprofile-documentation'>
@ -2852,23 +2852,23 @@
focus to the selected function, and so on. focus to the selected function, and so on.
</para> </para>
<note> <informalexample>
Tying It Together: If you like sysprof's 'caller-oriented' <emphasis>Tying it Together:</emphasis> If you like sysprof's 'caller-oriented'
display, you may be able to approximate it in other tools as display, you may be able to approximate it in other tools as
well. For example, 'perf report' has the -g (--call-graph) well. For example, 'perf report' has the -g (--call-graph)
option that you can experiment with; one of the options is option that you can experiment with; one of the options is
'caller' for an inverted caller-based callgraph display. 'caller' for an inverted caller-based callgraph display.
</note> </informalexample>
<note> <informalexample>
Tying It Together: sysprof does have build options to enable <emphasis>Tying it Together:</emphasis> sysprof does have build options to enable
use of the perf_event subsystem and benefit from the perf_event use of the perf_event subsystem and benefit from the perf_event
infrastructure by adding support for something other than infrastructure by adding support for something other than
system-wide profiling i.e. per-process or workload profiling, system-wide profiling i.e. per-process or workload profiling,
but the version in danny doesn't yet take advantage of those but the version in danny doesn't yet take advantage of those
capabilities (sysprof officially added the ability. capabilities (sysprof officially added the ability.
to make use of perf_events just as we were going to press). to make use of perf_events just as we were going to press).
</note> </informalexample>
</section> </section>
<section id='sysprof-documentation'> <section id='sysprof-documentation'>