From: compudj
This batch analysis module can be invoked like this :
+
It permits to call any registered action to perform in batch mode on all the
+trace set, which consists of the traces loaded on the command line. Actions that
+are built in the batchAnalysis module are statistics computation. They can be
+triggered by using the -s (--stats) switch.
+
However, the batchAnalysis module is mostly a backend for every other text
+module that does batch computation over a complete trace set.
+
This batch analysis module can be invoked like this :
-
It permits to call any registered action to perform in batch mode on all the
-trace set, which consists of the traces loaded on the command line. Actions that
-are built in the batchAnalysis module are statistics computation. They can be
-triggered by using the -s (--stats) switch.
-
However, the batchAnalysis module is mostly a backend for every other text
-module that does batch computation over a complete trace set.
-
This batch analysis module can be invoked like this :
-
It permits to call any registered action to perform in batch mode on all the
-trace set, which consists of the traces loaded on the command line. Actions that
-are built in the batchAnalysis module are statistics computation. They can be
-triggered by using the -s (--stats) switch.
-
However, the batchAnalysis module is mostly a backend for every other text
-module that does batch computation over a complete trace set.
-
This batch analysis module can be invoked like this :
-
It permits to call any registered action to perform in batch mode on all the
-trace set, which consists of the traces loaded on the command line. Actions that
-are built in the batchAnalysis module are statistics computation. They can be
-triggered by using the -s (--stats) switch.
-
However, the batchAnalysis module is mostly a backend for every other text
-module that does batch computation over a complete trace set.
-Chapter 4. Using LTTV text modules
4.1. The batch analysis module
$ lttv -L path/to/lib/plugins -m batchAnalysis\
+-t trace1 -t trace2 ...
+
Chapter 4. Using LTTV text modules
4.1. The batch analysis module
$ lttv -L path/to/lib/plugins -m batchAnalysis\
--t trace1 -t trace2 ...
-
Chapter 4. Using LTTV text modules
4.1. The batch analysis module
$ lttv -L path/to/lib/plugins -m batchAnalysis\
--t trace1 -t trace2 ...
-
Chapter 4. Using LTTV text modules
4.1. The batch analysis module
$ lttv -L path/to/lib/plugins -m batchAnalysis\
--t trace1 -t trace2 ...
-
Linux Trace Toolkit Viewer (LTTV) is the second generation of visualization -tool. It is -based on a trace format (the files where the data is recorded on disk) slightly -different from LTT. As for now, November 29, 2004, the implementation of the new -trace format in LTT is still not done, we must use a conversion tool to -transform the original LTT traces to the new format. +tool. It is based on a trace format (the files where the data is recorded on +disk) written by the LTTng tracer.
This document explains all the steps that are necessary in order to record a diff --git a/ltt/branches/poly/doc/user/user_guide/html/c25.html b/ltt/branches/poly/doc/user/user_guide/html/c25.html index c17f4f03..8c36ae80 100644 --- a/ltt/branches/poly/doc/user/user_guide/html/c25.html +++ b/ltt/branches/poly/doc/user/user_guide/html/c25.html @@ -13,8 +13,8 @@ REL="PREVIOUS" TITLE="Introduction" HREF="c20.html">
Next2.1. Installing LTTV2.1. Installing LTTng and LTTVFirst, you must download the latests version of LTTV. You should get it from -this site : Follow the QUICKSTART guide found at +ltt.polymtl.ca. -I suggest that you get it from the "Packages" section.
You need a recent gcc compiler to compile the project. You might want to use gcc -3.2 or newer. -You will also need some libraries in order to compile it. They are described in -the README of the LTTV package. These are GTK 2.0, GLIB 2.0, "popt" and Pango 1.0. -Install them if they are not on your system. Remember that if you use a package -manager from you favourite Linux distribution, you will need to specifically -install the librairies'development packages. -
Then, you are ready to compile LTTV. Extract and untar the file you previously -downloaded : -
$ tar -xvzof LinuxTraceToolkitViewer-x.x-dddddddd.tar.bz2 -
Then, go to the directory newly created, and type : -
$ ./configure -$ make -# make install (as root) -
At this point, LTTV is installed in the default directory. You may find the lttv executable in /usr/local/bin and the librairies in /usr/local/lib. You will also notice the presence of the convert executable in /usr/local/bin. This tool will be used later to convert from the Linux Trace Toolkit trace format to the LTTV format.
You are now ready to go to the next step : installing the LTT kernel tracer. -
This section describes the main functionnalities that are provided by the LTTV +GUI and how to use them. +
By default, when the lttv GUI starts with all the graphical modules loaded, +it loads the statistics viewer, the control flow viewer, and the detailed event +list inside a tab. Other viewers can be added later to this tab by interacting +with the main window. Let's describe the operations available on the window : +
Linux Trace Toolkit Viewer GUI
This toolbar allows you to navigate through the basic functionnalities of LTTV. +The first button opens a new window and the second one, a new tab. You can leave +your mouse over the buttons to read the information provided by the tooltips. +
This notebook, containing different tabs, lets you select the "Trace Set" you +want to interact with. A trace set is an aggregation of traces, synchronised in +time. You may also want to use one tab per viewer by simply cloning the traceset +to a new tab. This way, you can have vertically stacked viewers in one tab, as +well as different viewers, independant from the time interval. Note that once +the Trace Set cloning is done, each trace set becomes completely independant. +For Traceset cloning, see the File Menu. +
These buttons let you control the computation in progress on a trace. As +sometimes the computation may last for a while, you may want to stop it, restart +it from the beginning or simply to continue from where you stopped. This is +exactly what those three buttons offer you. +
Buttons on the right side of the last spacer are semantically different from the +others. While the other buttons at the left side of the bar are built in the +lttv program and let you operate the basic functionnalities, the buttons at the +right side let you add a viewer to the active Tab. They belong to the +viewers themselves. The number of buttons that appears there should directly +depend on the number of viewer's modules loaded. +
This is a tree representing the multiple statistics available for the current +traceset. This is shown by the guistatistics viewer. +
This is the Y axis of the guicontrolflow viewer. It shows the process list of +the traced system. You may notice that it grows : it dynamically adds +process when they appear in the trace. +
This is a (missing) time bar for the X axis. Maybe will it be used for viewer +specific buttons eventually. Work in progress. +
The is the current time selected. The concept of current event and current time +selected is synchronised in a Tab for all the viewers. The control flow viewer +shows it a vertical white dotted line. You move this marker by clicking on the +background of the process state graph. This graph shows evolution of each +process's state through time. The meaning of the colors will be explained later. +
This is the details event list. It shown the detailed information about each +event of the trace. It is synchronised with the current time and current event, +so selecting an event changes other viewer's current time and reciprocally. +
You can enter the values of start time and end time you wish to see on the +screen here. It also supports pasting time as text input, simply by clicking of +the "Time Frame", "start" or "end:" fields. A valid entry consists of any +digital input separated by any quantity of non digital characters. For example : +"I start at 356247.124626 and stop at 724524.453455" would be a valid input +for the "Time Frame" field. +
This horizontal scrollbar modifies the window of time shown by all the viewers +in the tab. It is linked with the fields below it (described at number 10 and +12). Another way to modify the time shown is to use the zoom buttons of the +toolbar (yes, the ones that looks like magnifying glasses). +
This field works just like the "Time Frame" field. It modifies the current time +selected by the viewers. For example, changing its value will change the current +event selected by the detailed events list and the current time selected by the +control flow viewer. +
This section describes the main functionnalities that are provided by the LTTV -GUI and how to use them. -
By default, when the lttv GUI starts with all the graphical modules loaded, -it loads the statistics viewer, the control flow viewer, and the detailed event -list inside a tab. Other viewers can be added later to this tab by interacting -with the main window. Let's describe the operations available on the window : -
Linux Trace Toolkit Viewer GUI
This toolbar allows you to navigate through the basic functionnalities of LTTV. -The first button opens a new window and the second one, a new tab. You can leave -your mouse over the buttons to read the information provided by the tooltips. -
This notebook, containing different tabs, lets you select the "Trace Set" you -want to interact with. A trace set is an aggregation of traces, synchronised in -time. You may also want to use one tab per viewer by simply cloning the traceset -to a new tab. This way, you can have vertically stacked viewers in one tab, as -well as different viewers, independant from the time interval. Note that once -the Trace Set cloning is done, each trace set becomes completely independant. -For Traceset cloning, see the File Menu. -
These buttons let you control the computation in progress on a trace. As -sometimes the computation may last for a while, you may want to stop it, restart -it from the beginning or simply to continue from where you stopped. This is -exactly what those three buttons offer you. -
Buttons on the right side of the last spacer are semantically different from the -others. While the other buttons at the left side of the bar are built in the -lttv program and let you operate the basic functionnalities, the buttons at the -right side let you add a viewer to the active Tab. They belong to the -viewers themselves. The number of buttons that appears there should directly -depend on the number of viewer's modules loaded. -
This is a tree representing the multiple statistics available for the current -traceset. This is shown by the guistatistics viewer. -
This is the Y axis of the guicontrolflow viewer. It shows the process list of -the traced system. You may notice that it grows : it dynamically adds -process when they appear in the trace. -
This is a (missing) time bar for the X axis. Maybe will it be used for viewer -specific buttons eventually. Work in progress. -
The is the current time selected. The concept of current event and current time -selected is synchronised in a Tab for all the viewers. The control flow viewer -shows it a vertical white dotted line. You move this marker by clicking on the -background of the process state graph. This graph shows evolution of each -process's state through time. The meaning of the colors will be explained later. -
This is the details event list. It shown the detailed information about each -event of the trace. It is synchronised with the current time and current event, -so selecting an event changes other viewer's current time and reciprocally. -
You can enter the values of start time and end time you wish to see on the -screen here. It also supports pasting time as text input, simply by clicking of -the "Time Frame", "start" or "end:" fields. A valid entry consists of any -digital input separated by any quantity of non digital characters. For example : -"I start at 356247.124626 and stop at 724524.453455" would be a valid input -for the "Time Frame" field. -
This horizontal scrollbar modifies the window of time shown by all the viewers -in the tab. It is linked with the fields below it (described at number 10 and -12). Another way to modify the time shown is to use the zoom buttons of the -toolbar (yes, the ones that looks like magnifying glasses). -
This field works just like the "Time Frame" field. It modifies the current time -selected by the viewers. For example, changing its value will change the current -event selected by the detailed events list and the current time selected by the -control flow viewer. -
This section describes the main functionnalities that are provided by the LTTV -GUI and how to use them. -
By default, when the lttv GUI starts with all the graphical modules loaded, -it loads the statistics viewer, the control flow viewer, and the detailed event -list inside a tab. Other viewers can be added later to this tab by interacting -with the main window. Let's describe the operations available on the window : -
Linux Trace Toolkit Viewer GUI
This toolbar allows you to navigate through the basic functionnalities of LTTV. -The first button opens a new window and the second one, a new tab. You can leave -your mouse over the buttons to read the information provided by the tooltips. -
This notebook, containing different tabs, lets you select the "Trace Set" you -want to interact with. A trace set is an aggregation of traces, synchronised in -time. You may also want to use one tab per viewer by simply cloning the traceset -to a new tab. This way, you can have vertically stacked viewers in one tab, as -well as different viewers, independant from the time interval. Note that once -the Trace Set cloning is done, each trace set becomes completely independant. -For Traceset cloning, see the File Menu. -
These buttons let you control the computation in progress on a trace. As -sometimes the computation may last for a while, you may want to stop it, restart -it from the beginning or simply to continue from where you stopped. This is -exactly what those three buttons offer you. -
Buttons on the right side of the last spacer are semantically different from the -others. While the other buttons at the left side of the bar are built in the -lttv program and let you operate the basic functionnalities, the buttons at the -right side let you add a viewer to the active Tab. They belong to the -viewers themselves. The number of buttons that appears there should directly -depend on the number of viewer's modules loaded. -
This is a tree representing the multiple statistics available for the current -traceset. This is shown by the guistatistics viewer. -
This is the Y axis of the guicontrolflow viewer. It shows the process list of -the traced system. You may notice that it grows : it dynamically adds -process when they appear in the trace. -
This is a (missing) time bar for the X axis. Maybe will it be used for viewer -specific buttons eventually. Work in progress. -
The is the current time selected. The concept of current event and current time -selected is synchronised in a Tab for all the viewers. The control flow viewer -shows it a vertical white dotted line. You move this marker by clicking on the -background of the process state graph. This graph shows evolution of each -process's state through time. The meaning of the colors will be explained later. -
This is the details event list. It shown the detailed information about each -event of the trace. It is synchronised with the current time and current event, -so selecting an event changes other viewer's current time and reciprocally. -
You can enter the values of start time and end time you wish to see on the -screen here. It also supports pasting time as text input, simply by clicking of -the "Time Frame", "start" or "end:" fields. A valid entry consists of any -digital input separated by any quantity of non digital characters. For example : -"I start at 356247.124626 and stop at 724524.453455" would be a valid input -for the "Time Frame" field. -
This horizontal scrollbar modifies the window of time shown by all the viewers -in the tab. It is linked with the fields below it (described at number 10 and -12). Another way to modify the time shown is to use the zoom buttons of the -toolbar (yes, the ones that looks like magnifying glasses). -
This field works just like the "Time Frame" field. It modifies the current time -selected by the viewers. For example, changing its value will change the current -event selected by the detailed events list and the current time selected by the -control flow viewer. -
Linux Trace Toolkit Viewer User Guide | ||
---|---|---|
Prev | Chapter 4. Using LTTV text modules |
The goal of this module is to convert the binary data of the traces into +a formatted text file. +
The text dump module is a good example of a usage of the batch analysis module +backend. In fact, the text dump module depends on it. You don't need to +explicitly load the batchAnalysis module though, as lttv offers a rich module +backend that deals with the dependencies, loading the module automatically if +needed. +
The text dump module is invoked just like the batchAnalysis module. It adds more +options that can be specified in argument. You may specify the -o switch for the +output file name of the text dump. You can enable the output of the field names +(the identifier of the fields) with the -l switch. The -s switch, for process +states, is very useful to indicate the state in which the process is when the +event happens. +
If you use the --help option on the textDump module, you will see all the detail +about the switches that can be used to show per cpu statistics and per process +statistics. You will notice that you can use both the switches for the +batchAnalysis module and those for textDump. You will also notice that the +options --process_state (from textDump) and --stats (from batchAnalysis) has the +same short name "-s". If you choose to invoke this option using the short name, +it will use the option of the last module loaded just before the -s switch. +
For exemple, if you load the textDump module with -m textDump, it will first +load the batchAnalysis module, and then load itself. As it is the last module +loaded, the -s switch used after it will signify --process_stats. On the other +hand, if you choose to specify explicitly the loading of both modules like this +: +
$ lttv -L path/to/lib/plugins -m batchAnalysis -s\ +-m textDump -s -t trace +
The first "-s" will invoke batchAnalysis --stats and the second "-s" will invoke +textDump --process_state. The list of options generated by --help follows the +order of registration of the options by the modules, therefore the invocation +order of the modules. +
Control Flow View Color Legend
Here is a description of the colors used in the control flow view. Each color -represents a state of the process at a given time. -
White : this color is used for process from which state is not known. It may -happen when you seek quickly at a far time in the trace just after it has been -launched. At that moment, the precomputed state information is incomplete. The -"unknown" state is used to identify this. Note that the viewer gets refreshed -once the precomputation ends. -
Green : This color is only used for process when they are running in user mode. -That includes execution of all the source code of an executable as well as the -libraries it uses. -
Pale blue : A process is doing a system call to the kernel, and the mode is -switched from process limited rights to super user mode. Only code from the -kernel (including modules) should be run in that state. -
Yellow : The kernel is running a trap that services a fault. The most frequent -trap is the memory page fault trap : it is called every time a page is missing -from physical memory. -
Orange : IRQ servicing routine is running. It interrupts the currently running -process. As the IRQ does not change the currently running process (on some -architectures it uses the same stack as the process), the IRQ state is shown in -the state of the process. IRQ can be nested : a higher priority interrupt can -interrupt a lower priority interrupt. -
Dark red : A process in that state is waiting for an input/output operation to -complete before it can continue its execution. -
Dark yellow : A process is ready to run, but waiting to get the CPU (a schedule -in event). -
Dark purple : A process in zombie state. This state happens when a process -exits and then waits for the parent to wait for it (wait() or waitpid()). -
Dark green : A process has just been created by its parent and is waiting for -first scheduling. -
Magenta : The process has exited, but still has the control of the CPU. It may -happend if it has some tasks to do in the exit system call. -
Control Flow View Color Legend
Here is a description of the colors used in the control flow view. Each color -represents a state of the process at a given time. -
White : this color is used for process from which state is not known. It may -happen when you seek quickly at a far time in the trace just after it has been -launched. At that moment, the precomputed state information is incomplete. The -"unknown" state is used to identify this. Note that the viewer gets refreshed -once the precomputation ends. -
Green : This color is only used for process when they are running in user mode. -That includes execution of all the source code of an executable as well as the -libraries it uses. -
Pale blue : A process is doing a system call to the kernel, and the mode is -switched from process limited rights to super user mode. Only code from the -kernel (including modules) should be run in that state. -
Yellow : The kernel is running a trap that services a fault. The most frequent -trap is the memory page fault trap : it is called every time a page is missing -from physical memory. -
Orange : IRQ servicing routine is running. It interrupts the currently running -process. As the IRQ does not change the currently running process (on some -architectures it uses the same stack as the process), the IRQ state is shown in -the state of the process. IRQ can be nested : a higher priority interrupt can -interrupt a lower priority interrupt. -
Pink : SoftIRQ handler is running. A SoftIRQ is normally triggered by an -interrupt that whishes to have some work done very soon, but not "now". This is -especially useful, for example, to have the longest part of the network stack -traversal done : a too long computation in the interrupt handler would increase -the latency of the system. Therefore, doing the long part of the computation in -a softirq that will be run just after the IRQ handler exits will permits to do -this work while interrupts are enabled, without increasing the system latency. -
Dark red : A process in that state is waiting for an input/output operation to -complete before it can continue its execution. -
Dark yellow : A process is ready to run, but waiting to get the CPU (a schedule -in event). -
Dark purple : A process in zombie state. This state happens when a process -exits and then waits for the parent to wait for it (wait() or waitpid()). -
Dark green : A process has just been created by its parent and is waiting for -first scheduling. -
Magenta : The process has exited, but still has the control of the CPU. It may -happend if it has some tasks to do in the exit system call. -
Linux Trace Toolkit Viewer User Guide | ||
---|---|---|
Prev | Chapter 4. Using LTTV text modules |
The goal of this module is to convert the binary data of the traces into -a formatted text file. -
The text dump module is a good example of a usage of the batch analysis module -backend. In fact, the text dump module depends on it. You don't need to -explicitly load the batchAnalysis module though, as lttv offers a rich module -backend that deals with the dependencies, loading the module automatically if -needed. -
The text dump module is invoked just like the batchAnalysis module. It adds more -options that can be specified in argument. You may specify the -o switch for the -output file name of the text dump. You can enable the output of the field names -(the identifier of the fields) with the -l switch. The -s switch, for process -states, is very useful to indicate the state in which the process is when the -event happens. -
If you use the --help option on the textDump module, you will see all the detail -about the switches that can be used to show per cpu statistics and per process -statistics. You will notice that you can use both the switches for the -batchAnalysis module and those for textDump. You will also notice that the -options --process_state (from textDump) and --stats (from batchAnalysis) has the -same short name "-s". If you choose to invoke this option using the short name, -it will use the option of the last module loaded just before the -s switch. -
For exemple, if you load the textDump module with -m textDump, it will first -load the batchAnalysis module, and then load itself. As it is the last module -loaded, the -s switch used after it will signify --process_stats. On the other -hand, if you choose to specify explicitly the loading of both modules like this -: -
$ lttv -L path/to/lib/plugins -m batchAnalysis -s\ --m textDump -s -t trace -
The first "-s" will invoke batchAnalysis --stats and the second "-s" will invoke -textDump --process_state. The list of options generated by --help follows the -order of registration of the options by the modules, therefore the invocation -order of the modules. -
Linux Trace Toolkit Viewer User Guide | ||
---|---|---|
Prev | Chapter 4. Using LTTV text modules |
The goal of this module is to convert the binary data of the traces into -a formatted text file. -
The text dump module is a good example of a usage of the batch analysis module -backend. In fact, the text dump module depends on it. You don't need to -explicitly load the batchAnalysis module though, as lttv offers a rich module -backend that deals with the dependencies, loading the module automatically if -needed. -
The text dump module is invoked just like the batchAnalysis module. It adds more -options that can be specified in argument. You may specify the -o switch for the -output file name of the text dump. You can enable the output of the field names -(the identifier of the fields) with the -l switch. The -s switch, for process -states, is very useful to indicate the state in which the process is when the -event happens. -
If you use the --help option on the textDump module, you will see all the detail -about the switches that can be used to show per cpu statistics and per process -statistics. You will notice that you can use both the switches for the -batchAnalysis module and those for textDump. You will also notice that the -options --process_state (from textDump) and --stats (from batchAnalysis) has the -same short name "-s". If you choose to invoke this option using the short name, -it will use the option of the last module loaded just before the -s switch. -
For exemple, if you load the textDump module with -m textDump, it will first -load the batchAnalysis module, and then load itself. As it is the last module -loaded, the -s switch used after it will signify --process_stats. On the other -hand, if you choose to specify explicitly the loading of both modules like this -: -
$ lttv -L path/to/lib/plugins -m batchAnalysis -s\ --m textDump -s -t trace -
The first "-s" will invoke batchAnalysis --stats and the second "-s" will invoke -textDump --process_state. The list of options generated by --help follows the -order of registration of the options by the modules, therefore the invocation -order of the modules. -
Linux Trace Toolkit Viewer User Guide | ||
---|---|---|
Prev | Chapter 4. Using LTTV text modules |
The goal of this module is to convert the binary data of the traces into -a formatted text file. -
The text dump module is a good example of a usage of the batch analysis module -backend. In fact, the text dump module depends on it. You don't need to -explicitly load the batchAnalysis module though, as lttv offers a rich module -backend that deals with the dependencies, loading the module automatically if -needed. -
The text dump module is invoked just like the batchAnalysis module. It adds more -options that can be specified in argument. You may specify the -o switch for the -output file name of the text dump. You can enable the output of the field names -(the identifier of the fields) with the -l switch. The -s switch, for process -states, is very useful to indicate the state in which the process is when the -event happens. -
If you use the --help option on the textDump module, you will see all the detail -about the switches that can be used to show per cpu statistics and per process -statistics. You will notice that you can use both the switches for the -batchAnalysis module and those for textDump. You will also notice that the -options --process_state (from textDump) and --stats (from batchAnalysis) has the -same short name "-s". If you choose to invoke this option using the short name, -it will use the option of the last module loaded just before the -s switch. -
For exemple, if you load the textDump module with -m textDump, it will first -load the batchAnalysis module, and then load itself. As it is the last module -loaded, the -s switch used after it will signify --process_stats. On the other -hand, if you choose to specify explicitly the loading of both modules like this -: -
$ lttv -L path/to/lib/plugins -m batchAnalysis -s\ --m textDump -s -t trace -
The first "-s" will invoke batchAnalysis --stats and the second "-s" will invoke -textDump --process_state. The list of options generated by --help follows the -order of registration of the options by the modules, therefore the invocation -order of the modules. -
Starting the graphical mode with the basic viewer activated is as simple as : +
$ lttv-gui +
Using the text mode is very simple too. Look in /usr/local/lib/lttv/plugins for +the list of modules. You may use the --help switch to get basic help on the +command line parameters of every loaded modules. To simply output the events of +a trace in a text file, try the textDump module. The batchAnalysis module +permits to do batch mode analysis (state and statistics calculation ) on a +trace. +
$ lttv -L /usr/local/lib/lttv/plugins -m textDump --help +
The goal of this guide is not to describe the Linux Trace Toolkit project in -details, as it is a -seperate project for now. It just gives pointers to the basic steps you must -take in order to generate a trace suitable for conversion. -
First, go to the ltt.polymtl.ca -website, in the "Patches for the Official LTT" section. Use the latest version -of patches available. The file name convention used goes like this : -aaaaaa-x.x--bbbbb-y.y.patch. That means a patch made for aaaaa, release x.x, -that adds bbbbb, release y.y to it. Notice the presence of the -- sign that -separates the "from" field from the name of the patch applied. This way, it's -impossible to be mixed up on the specific sequence of patch application. I -suggest that you use the "relayfs", "ltt" and then "md" patches. The "md" patch -adds events useful to LTTV that are not in the official LTT. -
Once you have the patches you need, get the matching Linux kernel version, apply -the patches on it, configure it, install it, reboot with the new kernel. You then -have an instrumented kernel ready for tracing. If you have problems during this phase, -please refer to www.opersys.com/ltt. If you need -instructions about how to recompile a kernel, see -Kernel-HOWTO. -
In order to install the LTT trace recording daemon, you should get the latest -TraceToolkit (or ltt) package from the LTT ftp site. -Use the link "Official Linux Trace Toolkit Packages" on the -ltt.polymtl.ca webpage to access it. -As of November 30, 2004, the most recent version is 0.9.6-pre3. -
Then, you should apply the TraceToolkit patches from the LTTV website related -to the package version. Get them from the "Patches for the Official LTT" -section. -
You are now ready to install the daemon in your system. Please refer to the -documentation in the package for details. -
You may now use the following command to record a sample 30 seconds trace in -your current directory. Command line switches are described on the official -LTT website. -
#tracedaemon -ts30 sample.out sample.proc (as root) userinput> -
If you used the default directory for installation, you should find the -conversion tool in /usr/local/bin/convert. Before using it, some other files are -necessary. You will find them in -/usr/local/share/LinuxTraceToolkitViewer/convert/. Those are sysInfo and -core.xml. -
sysInfo is a script that get informations about the traced computer. It should -be invoked like this : -
$ sh /usr/local/LinuxTraceToolkitViewer/convert/sysInfo -
It created a file named sysInfo.out. This file has to be present in the current -directory where the convert tool will be executed. I suggest that you choose a -destination directory for converted traces right now, put sysInfo.out in it, at -use it as current directory for running the convert tool. -
Once the sysInfo.out file is ready and you have a trace ready for conversion, -you should invoke convert like the following example. This is for a uniprocessor -computer. If you whish to get detailed explanation on the parameters, simply -execute the convert tool without any. You may also wish to see the -/usr/local/LinuxTraceToolkitViewer/convert/README file. -
$ /usr/local/bin/convert sample.proc 1 sample.trace sample.converted -
You must then copy the core event definition file to the converted trace directory : -
$ cp /usr/local/share/LinuxTraceToolkitViewer/convert/core.xml sample.converted/ -
You now have a converted trace ready for visualization in LTTV. Congratulations! -
If you used the default directory for installation, you should find the -conversion tool in /usr/local/bin/convert. Before using it, some other files are -necessary. You will find them in -/usr/local/share/LinuxTraceToolkitViewer/convert/. Those are sysInfo and -core.xml. -
sysInfo is a script that get informations about the traced computer. It should -be invoked like this : -
$ sh /usr/local/LinuxTraceToolkitViewer/convert/sysInfo -
It creates a file named sysInfo.out. This file has to be present in the current -directory where the convert tool will be executed. I suggest that you choose a -destination directory where will be written converted traces right now, put sysInfo.out in it, at -use it as current directory for running the convert tool. -
Once the sysInfo.out file is ready and you have a trace ready for conversion, -you should invoke convert like the following example. This is for a uniprocessor -computer. If you whish to get detailed explanation on the parameters, simply -execute the convert tool without any option. You may also wish to see the -/usr/local/LinuxTraceToolkitViewer/convert/README file. -
$ /usr/local/bin/convert sample.proc 1 sample.trace sample.converted -
You must then copy the core event definition file to the converted trace directory : -
$ cp /usr/local/share/LinuxTraceToolkitViewer/convert/core.xml sample.converted/ -
You now have a converted trace ready for visualization in LTTV. Congratulations! -
Starting the graphical mode with the basic viewer activated is as simple as : -
$ lttv -L /usr/local/lib/lttv/plugins -m lttvwindow\ --m guievents -m guicontrolflow -m guistatistics -t sample.converted/ -
Using the text mode is very simple too. Look in /usr/local/lib/lttv/plugins for -the list of modules. You may use the --help switch to get basic help on the -command line parameters of every loaded modules. To simply output the events of -a trace in a text file, try the textDump module. The batchAnalysis module -permits to do batch mode analysis (state and statistics calculation ) on a -trace. -
$ lttv -L /usr/local/lib/lttv/plugins -m textDump --help -
Control Flow View Color Legend
Starting the graphical mode with the basic viewer activated is as simple as : +> Here is a description of the colors used in the control flow view. Each color +represents a state of the process at a given time.
$ lttv -L /usr/local/lib/lttv/plugins -m lttvwindow\ --m guievents -m guicontrolflow -m guistatistics -t sample.converted/ -
Using the text mode is very simple too. Look in /usr/local/lib/lttv/plugins for -the list of modules. You may use the --help switch to get basic help on the -command line parameters of every loaded modules. To simply output the events of -a trace in a text file, try the textDump module. The batchAnalysis module -permits to do batch mode analysis (state and statistics calculation ) on a -trace. +>
White : this color is used for process from which state is not known. It may +happen when you seek quickly at a far time in the trace just after it has been +launched. At that moment, the precomputed state information is incomplete. The +"unknown" state is used to identify this. Note that the viewer gets refreshed +once the precomputation ends. +
Green : This color is only used for process when they are running in user mode. +That includes execution of all the source code of an executable as well as the +libraries it uses. +
Pale blue : A process is doing a system call to the kernel, and the mode is +switched from process limited rights to super user mode. Only code from the +kernel (including modules) should be run in that state. +
Yellow : The kernel is running a trap that services a fault. The most frequent +trap is the memory page fault trap : it is called every time a page is missing +from physical memory.
$ lttv -L /usr/local/lib/lttv/plugins -m textDump --help -
Orange : IRQ servicing routine is running. It interrupts the currently running +process. As the IRQ does not change the currently running process (on some +architectures it uses the same stack as the process), the IRQ state is shown in +the state of the process. IRQ can be nested : a higher priority interrupt can +interrupt a lower priority interrupt. +
Pink : SoftIRQ handler is running. A SoftIRQ is normally triggered by an +interrupt that whishes to have some work done very soon, but not "now". This is +especially useful, for example, to have the longest part of the network stack +traversal done : a too long computation in the interrupt handler would increase +the latency of the system. Therefore, doing the long part of the computation in +a softirq that will be run just after the IRQ handler exits will permits to do +this work while interrupts are enabled, without increasing the system latency. +
Dark red : A process in that state is waiting for an input/output operation to +complete before it can continue its execution. +
Dark yellow : A process is ready to run, but waiting to get the CPU (a schedule +in event). +
Dark purple : A process in zombie state. This state happens when a process +exits and then waits for the parent to wait for it (wait() or waitpid()). +
Dark green : A process has just been created by its parent and is waiting for +first scheduling. +
Magenta : The process has exited, but still has the control of the CPU. It may +happend if it has some tasks to do in the exit system call. +