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