man.bsd.lv manual page server

Manual Page Search Parameters
KTRDUMP(8) System Manager's Manual KTRDUMP(8)

ktrdump — print kernel ktr trace buffer

ktrdump [-acdfilnpqrstx] [-A factor] [-N execfile] [-M corefile] [-o outfile]

The ktrdump utility is used to dump the contents of the kernel ktr trace buffer.

The following options are available:

Print most fields. Implies -c -i -x -p -r, and -s. Note that -f is not included.
Print the CPU number that each entry was logged from.
Dump an event stream to the file specified with -o. This stream can be examined with evtranalyze(1).
Print the file and line number that each entry was logged from.
Print the ID string field, identifying the facility being logged.
ktrdump will loop waiting for new data rather than exit.
ktrdump 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.
Print the trace data.
Quiet mode; do not print the column header.
Print relative timestamps in microseconds, rather than absolute TSC timestamps.
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 periodically calculate the drift between each CPU's TSC and apply a correction.
Print the timestamp for each entry.
Print the call chain leading up to the procedure which issued the KTR.
factor
Specify a correction factor to be applied to attempt to remove the overhead of the KTR logging call itself.
execfile
The kernel image to resolve symbols from. The default is the value returned via getbootfile(3).
corefile
The core file or memory image to read from. The default is /dev/mem.
outfile
The file to write the output to. The default is standard output.

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 additional 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 different 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 recommended. 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.

ktr(4), ktr(9)

The ktrdump utility first appeared in FreeBSD 5.0.

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.

November 9, 2008 DragonFly-5.6.1