1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279
|
FxT - Fast User or Kernel Tracing
University of New Hampshire
FxT is a fast tracing engine that can be used either in user land, in kernel
land, or both, maintained mostly by samuel.thibault@ens-lyon.org
FUT - Fast User Tracing
FUT is the Fast User Tracing, the User part of FxT. It permits
recording the execution trace along functions within applications (without any
kernel patching). To install FUT on your system, simply use the usual GNU way:
$ ./configure
$ make
$ sudo make install
This will notably install a fxt.pc file in /usr/local/lib/pkgconfig so that to
build your application you just need to add $(pkg-config --cflags fxt) to your
CFLAGS and $(pkg-cnfig --libs fxt) to your LDFLAGS.
tools/test.c shows an example of the use of FUT.
FKT - Fast Kernel Tracing
FKT is the Fast Kernel Tracing, the Kernel part of FxT. It permits
recording the execution trace along functions within the kernel. Its purpose is
originately to instrument parts of the kernel, but it also revealed to be useful
for debugging or teaching.
Please read 'INSTALL.FKT' first to setup FKT on your system for your kernel.
Note that you do _not_ need to install FKT if you only need the Userland
FUT part.
Once FKT is properly installed, running, the tools built and installed
in the PATH, tracing is quite easy:
fkt_record -f output -k 0xf -- scp machine:file .
Will trace the execution of 'scp machine:file .' and write the result
in file output. Then you can use fkt_print to analyze the recording (you
don't need to be running the fkt kernel, but having the proper modules in
/lib/modules might sometimes help).
fkt_print -f output -t output.timedat > stats
Then you can have a look at the stats file.
fkt_timestats output,timedat
Will produce output.eps, which will show you how long did each page of
data to get filled, hence, to some extent, the load of the system.
Table of contents
-----------------
- fkt_record
- fkt_setmask, fkt_enable and fkt_disable
- fkt_print
- Adding probes
fkt_record
----------
fkt_record opens /dev/fkt and the output file and calls sendfile()
between them, which triggers the tracing. Before calling sendfile(), it can
fork() to exec() a user program as needed. The recording stops whenever the
file system is full or the given size (-s option) is reached, or a signal is
caught. As a result, one can stop the recording by pressing ^C for instance,
or as soon as the son exits if any (it sends a SIGCLD to fkt_record).
Options:
-f file precises the output record file. The location of that file
should be carefully chosen: its recording shouldn't compete
with what is actually traced, since not only will it interfere
with the mere measures, but it may not be able to actually flush
the recording when some blasting is running for instance.
The best thing to do might be using a separate drive, with a
single big partition, and use its block device as file name,
since it would avoid all the filesystem stuff.
-k mask chooses which keymask will be set for the recording.
It defaults to 0x1, which is only system calls, irqs and traps,
but setting it to 0x3 activates probes from network device
drivers, setting it to 0x7 also activates the ip probes, while
setting it to 0x5 only activates ip probes.
include/linux/fkt.h holds the definition of KEYMASKs for sets
of probes which can be enabled and disable this way.
Avoiding including useless layers gives better measurements.
It can even be set to 0, which will prevent fkt from recording
anything before fkt_enable is used for instance.
-s size restricts the recording to a given size. Suffixes like G, M,
k are accepted. By default, the available size of the
filesystem or the block device will be used
-n prevents fkt_record from fork()ing, so pressing ^C will be
the only way to stop fkt_record.
-S System.map will load the given System.map file to include addresses
of every function of the kernel, enabling proper display
by fkt_print when -finstrument-functions in the built-in
kernel. If not given, only addresses available in
/proc/ksyms will be included in the trace. this option
may be set several times.
-p pow will ask fkt to allocate 2^pow pages for its recording buffer.
it is useful if load pikes are expected during the recording.
the default is 7.
-h prints some reference help
fkt_setmask, fkt_enable, fkt_disable
------------------------------------
These tools are particularly useful when fkt_record was given the -n
option: they modify the current keymask `on the fly' by doing an ioctl() on
/dev/fkt. For instance,
fkt_record -k 0 -n &
fkt_setmask 0xf
some network stuff
fkt_disable 1
some other network stuff
killall fkt_record
Will record both network stuff in the same record file, but the second
one will not have any device driver (bit 1, i.e. mask 0x2) probe entry.
fkt_print
---------
This tool analyzes a trace produced by fkt_record.
It first shows the recording header.
Then the full recording is dumped: for each probe triggered during the
recording, the following is shown:
- the time since last probe record for the same cpu
- the cpu on which it was running
- the pid of the current process on this cpu
- the code of the probe
- the name corresponding to the code
- the parameters of the probe, if any
It then shows some statistics computed during reading the recording.
- Cpu cycles: it should be quite similar between cpus
- Process cycles: the number of cycles spent between every process,
both user&kernel level, so this adds to 100%.
- Functions cycles: the time each function spent to achieve its work.
Note that testing is not computed here, so this doesn't adds to kernel time.
- Nesting summary: for each encountered function, the functions it
called are displayed along with the time they spent to achieve their work. The
cycles this function spent itself is also displayed, so this is a good summary
to know the balance of the whole work for this function.
- Accounting for every cycle exactly once: this summary shows each spent
cycle, either in system calls (S), traps (T), Irqs handling (I), kernel
functions (F) or processes: idle (i), fkt_record (f), son of fkt_record (u), or
other (o). Note that nesting is taken into account here, so the total should
be exactly 100%.
- Histogram account for every cycle exactly once: this is the same as
above, except it is drawn as an histogram, allowing fast comparisons, especially
between records.
Options:
-f file precises the input record file
-s pid asks fkt_print to start taking statistics when the first entry
for this pid is encountered.
setting pid to 0 asks for no statistics at all, and setting it
to -1 asks for full statistics (default).
-p pid asks fkt_print to start printing trace items when the first
entry for this pid is encountered. With a prepended '+', only
items for this pid will be printed.
setting pid to 0 asks for no printing at all, and setting it to
-1 asks for full printing (default).
-d enables debugging. It shouldn't be useful unless an analysis
error happens (prefixed with ===)
-k asks fkt_print to have the histogram only show kernel cycles,
getting rid of process time which might flatten it.
-b file asks fkt_print to print statistics about the fkt buffering
mecanism in the given file. fkt_bufstats can then be used to get
an .eps file from it, provided gnuplot is installed.
-t file asks fkt_print to print the time each page took to get filled.
fkt_timestats can be used to get an .eps from it. fkt_timestats
does the same, with a logarithmic scale.
To some extent, it quickly shows the load of the machine during
the recording.
-h prints some reference help
fkt_extract, fkt_select
-----------------------
The problem with big traces is that it takes a long time to analyze
them. fkt_extract can extract a subtrace from a trace:
fkt_extract trace_file1 trace_file2 23 4053
Will extract 4031 pages from trace file trace_file1, starting from page
23 and write them to trace_file2. All the headers are copied as well, so
fkt_print will still work on trace_file2.
To know the page numbers, you can use fkt_select.
fkt_select trace.timedat
Will open a window where the activity is drawn: it shows how fast pages
were filled during the trace, the x axis being absolute time in processor
cycles. a part of it can then be selected, zoomed, unzoomed, and finaly pressing
's' will print the extrema pages numbers on standard output, which can be used
as are.
trace.timedat is obtained by fkt_print thanks to the -t option.
Hopefully, -p 0 -s 0 can be set to fasten its run, if only the .timedat file is
wanted for extracting a small part of the trace for a thorough analysis for
instance.
Adding probes
-------------
The fastest way to add probes to file.c for instance is adding
CFLAGS_file.o += -finstrument-functions
to the Makefile, which tells gcc to automatically call probes at entry
and exit of every function of file.c. If file.o is loaded as a module, it should
be loaded *just before* launching fkt_record, for it needs both its address and
the file itself, to have the base address of the module in memory and the offset
of functions within the module.
The drawback is that you can't get parameters or return code for
instance. Adding probes to every function might also be too much.
Adding __attribute__ ((no_instrument_function)) before the name of a
function in its definition will prevent gcc from adding the call for this
function. Probes can then be added by hand:
void __attribute__ ((no_instrument_function)) myfun(int param1, int param2)
{
int ret=0;
FKT_PROBE2(FKT_SOME_KEYMASK,FKT_MYFUN_ENTRY_CODE,param1,param2);
work... Do some ret = -ESOMETHING if needed...
FKT_PROBE1(FKT_SOME_KEYMASK,FKT_MYFUN_EXIT_CODE,ret);
return ret;
}
FKT_MYFUN_ENTRY_CODE and FKT_MYFUN_EXIT_CODE must be uniquely defined in
include/linux/fkt.h and fkt/tools/names.c to be properly printed by fkt_print.
But -finstrument-functions and hand-inserted probes should be removed
from any production release, since it will fail to be built in any non-fkt
patched kernel.
--
vim: textwidth=80
|