Prev Next -Using LTTV graphical interface

Linux Trace Toolkit Viewer User Guide
Prev		Next

Chapter 3. Using LTTV graphical interface

3.1. LTTV main window

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. -

Prev	Home	Next
Running the executable with basic libraries		Control Flow View Colors

\ No newline at end of file diff --git a/ltt/branches/poly/doc/user/user_guide/html/index.html b/ltt/branches/poly/doc/user/user_guide/html/index.html index a74d736b..1661e62a 100644 --- a/ltt/branches/poly/doc/user/user_guide/html/index.html +++ b/ltt/branches/poly/doc/user/user_guide/html/index.html @@ -90,64 +90,49 @@ HREF="c25.html" >

2.1. Installing LTTVInstalling LTTng and LTTV

2.2. Installing LTT kernel tracer

2.3. Installing LTT trace recording daemon

2.4. Conversion from LTT to LTTV trace format

2.5. Running the executable with basic libraries

3. Using LTTV graphical interface

3.1. LTTV main window
3.2. Control Flow View Colors

4. Using LTTV text modules

4.1. The batch analysis module
4.2. The text dump module

Prev Prev Up -Control Flow View Colors

Linux Trace Toolkit Viewer User Guide
Prev	Chapter 3. Using LTTV graphical interface	Next

3.2. Control Flow View Colors

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. -

Prev	Home	Next
Using LTTV graphical interface	Up	Using LTTV text modules

\ No newline at end of file diff --git a/ltt/branches/poly/doc/user/user_guide/html/x130.html b/ltt/branches/poly/doc/user/user_guide/html/x130.html deleted file mode 100644 index 974e4e01..00000000 --- a/ltt/branches/poly/doc/user/user_guide/html/x130.html +++ /dev/null @@ -1,244 +0,0 @@ - -Control Flow View Colors

Linux Trace Toolkit Viewer User Guide
Prev	Chapter 3. Using LTTV graphical interface	Next

3.2. Control Flow View Colors

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. -

Prev	Home	Next
Using LTTV graphical interface	Up	Using LTTV text modules

\ No newline at end of file diff --git a/ltt/branches/poly/doc/user/user_guide/html/x169.html b/ltt/branches/poly/doc/user/user_guide/html/x169.html deleted file mode 100644 index d2409ac3..00000000 --- a/ltt/branches/poly/doc/user/user_guide/html/x169.html +++ /dev/null @@ -1,185 +0,0 @@ - -The text dump module

Linux Trace Toolkit Viewer User Guide
Prev	Chapter 4. Using LTTV text modules

4.2. The text dump module

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. -

Prev	Home
Using LTTV text modules	Up

\ No newline at end of file diff --git a/ltt/branches/poly/doc/user/user_guide/html/x174.html b/ltt/branches/poly/doc/user/user_guide/html/x174.html deleted file mode 100644 index e63e9589..00000000 --- a/ltt/branches/poly/doc/user/user_guide/html/x174.html +++ /dev/null @@ -1,185 +0,0 @@ - -The text dump module

Linux Trace Toolkit Viewer User Guide
Prev	Chapter 4. Using LTTV text modules

4.2. The text dump module

The goal of this module is to convert the binary data of the traces into -a formatted text file. -

$ lttv -L path/to/lib/plugins -m batchAnalysis -s\
--m textDump -s -t trace
-

Prev	Home
Using LTTV text modules	Up

\ No newline at end of file diff --git a/ltt/branches/poly/doc/user/user_guide/html/x78.html b/ltt/branches/poly/doc/user/user_guide/html/x32.html similarity index 86% rename from ltt/branches/poly/doc/user/user_guide/html/x78.html rename to ltt/branches/poly/doc/user/user_guide/html/x32.html index 676b4e25..174e8326 100644 --- a/ltt/branches/poly/doc/user/user_guide/html/x78.html +++ b/ltt/branches/poly/doc/user/user_guide/html/x32.html @@ -13,11 +13,11 @@ REL="UP" TITLE="Getting started" HREF="c25.html">Prev Next 2.5. Running the executable with basic libraries2.2. Running the executable with basic libraries

Starting the graphical mode with the basic viewer activated is as simple as : @@ -86,8 +86,7 @@ CLASS="prompt" >$ lttv -L /usr/local/lib/lttv/plugins -m lttvwindow\ --m guievents -m guicontrolflow -m guistatistics -t sample.converted/lttv-gui

Prev NextConversion from LTT to LTTV trace formatGetting started -Installing LTT kernel tracer

Linux Trace Toolkit Viewer User Guide
Prev	Chapter 2. Getting started	Next

2.2. Installing LTT kernel tracer

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. -

Prev	Home	Next
Getting started	Up	Installing LTT trace recording daemon

\ No newline at end of file diff --git a/ltt/branches/poly/doc/user/user_guide/html/x54.html b/ltt/branches/poly/doc/user/user_guide/html/x54.html deleted file mode 100644 index e2453f7f..00000000 --- a/ltt/branches/poly/doc/user/user_guide/html/x54.html +++ /dev/null @@ -1,179 +0,0 @@ - -Installing LTT trace recording daemon

Linux Trace Toolkit Viewer User Guide
Prev	Chapter 2. Getting started	Next

2.3. Installing LTT trace recording daemon

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>
-

Prev	Home	Next
Installing LTT kernel tracer	Up	Conversion from LTT to LTTV trace format

\ No newline at end of file diff --git a/ltt/branches/poly/doc/user/user_guide/html/x61.html b/ltt/branches/poly/doc/user/user_guide/html/x61.html deleted file mode 100644 index c58b1de7..00000000 --- a/ltt/branches/poly/doc/user/user_guide/html/x61.html +++ /dev/null @@ -1,204 +0,0 @@ - -Conversion from LTT to LTTV trace format

Linux Trace Toolkit Viewer User Guide
Prev	Chapter 2. Getting started	Next

2.4. Conversion from LTT to LTTV trace format

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! -

Prev	Home	Next
Installing LTT trace recording daemon	Up	Running the executable with basic libraries

\ No newline at end of file diff --git a/ltt/branches/poly/doc/user/user_guide/html/x64.html b/ltt/branches/poly/doc/user/user_guide/html/x64.html deleted file mode 100644 index 87d2a99c..00000000 --- a/ltt/branches/poly/doc/user/user_guide/html/x64.html +++ /dev/null @@ -1,204 +0,0 @@ - -Conversion from LTT to LTTV trace format

Linux Trace Toolkit Viewer User Guide
Prev	Chapter 2. Getting started	Next

2.4. Conversion from LTT to LTTV trace format

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! -

Prev	Home	Next
Installing LTT trace recording daemon	Up	Running the executable with basic libraries

\ No newline at end of file diff --git a/ltt/branches/poly/doc/user/user_guide/html/x81.html b/ltt/branches/poly/doc/user/user_guide/html/x81.html index 1e26c6d0..b2fd6878 100644 --- a/ltt/branches/poly/doc/user/user_guide/html/x81.html +++ b/ltt/branches/poly/doc/user/user_guide/html/x81.html @@ -2,7 +2,7 @@ Running the executable with basic librariesControl Flow View ColorsPrevChapter 2. Getting startedChapter 3. Using LTTV graphical interfaceNext

2.5. Running the executable with basic libraries3.2. Control Flow View Colors

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. +

Chapter 4. Using LTTV text modules

Chapter 4. Using LTTV text modules

Chapter 4. Using LTTV text modules

Chapter 3. Using LTTV graphical interface

Chapter 3. Using LTTV graphical interface

2.5. Running the executable with basic libraries3.2. Control Flow View Colors