KTRDUMP(8) BSD System Manager's Manual KTRDUMP(8)NAMEktrdump — print kernel ktr trace buffer
SYNOPSISktrdump [-acdfilnpqrstx] [-A factor] [-N execfile] [-M corefile]
[-o outfile]
DESCRIPTION
The ktrdump utility is used to dump the contents of the kernel ktr trace
buffer.
The following options are available:
-a Print most fields. Implies -c -i -x -p -r, and -s. Note
that -f is not included.
-c Print the CPU number that each entry was logged from.
-d Dump an event stream to the file specified with -o. This
stream can be examined with evtranalyze(1).
-f Print the file and line number that each entry was logged
from.
-i Print the ID string field, identifying the facility being
logged.
-lktrdump will loop waiting for new data rather than exit.
-nktrdump normally tries to translate the caller fields and
(when easily parsed) trace arguments into symbols. This
option forces hex values to be displayed instead. This
option will also cause relative timestamps to be displayed
as TSC timestamps rather than converted to microseconds.
-p Print the trace data.
-q Quiet mode; do not print the column header.
-r Print relative timestamps in microseconds, rather than abso‐
lute TSC timestamps.
-s Attempt to merge the KTR logs for all cpus into a single
time-sorted log. For the numbers to make any sense you
probably want to turn on the debug.ktr.resynchronize
sysctl(3) variable. This sysctl causes the kernel to peri‐
odically calculate the drift between each CPU's TSC and
apply a correction.
-t Print the timestamp for each entry.
-x Print the call chain leading up to the procedure which
issued the KTR.
-A factor Specify a correction factor to be applied to attempt to
remove the overhead of the KTR logging call itself.
-N execfile The kernel image to resolve symbols from. The default is
the value returned via getbootfile(3).
-M corefile The core file or memory image to read from. The default is
/dev/mem.
-o outfile The file to write the output to. The default is standard
output.
OPERATIONAL NOTES
Users of ktrdump should keep in mind that the act of trace logging will
itself affect execution overheads. On a 2Ghz cpu a logging call can take
anywhere from 40ns to 150ns to run.
The TSC counter is used on cpus equipped with it (which is all modern
cpus). The TSC counters may not be synchronized on SMP systems and may
drift even between cores on multi-core cpus. Enabling synchronization
between cpus via the debug.ktr.resynchronize sysctl will impose addi‐
tional system overheads and will generally only be accurate to within
100ns or so (and perhaps not even that good). Resynchronization only
occurs 10 times a second and serious drift will cause a great deal of
measurement noise when trying to compare events occurring on two differ‐
ent cpus.
Users using the -s option should be aware that events for each cpu are
independently logged and one cpu might have more events logged then
another, causing earlier events to be discarded sooner than other cpus.
The beginning portion of the sorted output may thus show MP related
events for one cpu with no corresponding events for other cpus.
It is possible to somewhat characterize KTR logging overheads by setting
the debug.ktr.testlogcnt sysctl and then observing test logging events in
the KTR output. Tests 1-3 log four dummy arguments while tests 4-6 log
no arguments.
It is possible to characterize IPI messaging latencies by setting the
debug.ktr.testipicnt sysctl. A small number between 1 and 1000 is recom‐
mended. This will cause the system to ping pong a single IPI message
between cpu 0 and cpu 1 asynchronously that number of times, as fast as
it can. A ktrdump should be performed almost immediately after setting
the sysctl or you might miss the logged events.
SEE ALSOktr(4), ktr(9)HISTORY
The ktrdump utility first appeared in FreeBSD 5.0.
AUTHORS
The ktrdump utility was originally implemented by Jake Burkholder
⟨jake@FreeBSD.org⟩. This manual page was originally written by Chad
David ⟨davidc@FreeBSD.org⟩. The program and manual page were rewritten
pretty much from scratch by Matthew Dillon for DragonFly.
BSD November 9, 2008 BSD
