ktracer.1m (2010 09)

k
ktracer(1M) ktracer(1M)
When Are Trace Records Captured?
The kernel captures one trace record each and every time that it encounters a trace point, as long as the
following situations occur:
• Tracing status is on.
• The process executing the trace point is selected for tracing.
• The CPU executing the trace point has memory allocated for its trace buffer.
Each trace record includes the following information:
• Sequence#
• CPU#
• Process ID (PID)
• Thread ID (TID)
• Function Name
• Caller Name and Offset
• Absolute Time (adjusted interval timer)
• Elapsed Time since previous trace record in cycles and in nanoseconds
• Stack Pointer
• Processor Status Register (PSR)
• Task Priority Register (TPR)
• Function Arguments (Procedure Parameters) arg0, arg1, ...
• Spinlock Depth
• Four kernel Global variables
Run the
ktracedump command to view the trace records that ktracer collects.
Security Restrictions
ktracer requires superuser privilege. The security of ktracer depends upon the protection of
superuser privilege. For systems using fine-grained privileges, PRIV_DEVOPS is required (see
privileges (5)).
Performance
ktracer incurs no performance penalty when no trace points are inserted. Trace points are inserted by
using the -I option which is explained in the Installing the Function List section. The performance cost
when trace points are inserted depends primarily on how often the trace points are hit or encountered.
Performance also depends also on the processor architecture and speed, cache hit rate and memory speed.
A performance estimate is a cost of 0.1 microseconds each time a trace point is hit.
For example, if a trace point is placed at the entry to the
hardclock()
function and hardclock() is
called 100 times per second, then the cost of tracing
hardclock() equals 100 times per second multi-
plied by 0.1 microseconds, which equals 10 microseconds per second, which equals a 0.001% overhead to
trace hardclock().
For another example, if the function
write() is called 100,000 times per second, the performance cost
would be 10 milliseconds per second to trace write(), which equals a 1% overhead.
The performance overhead of
ktracer directly correlates to the rate of traced function calls. The rate of
traced function calls depends on which functions are selected to trace, and upon the workload. Because
the vast majority of kernel functions are called infrequently, tracing 40,000 functions could occur with
nearly zero overhead. On the other hand, tracing solely the 10 most frequently executed kernel functions,
for example spinlock(), during a highly kernel intensive benchmark (SDET) extended the duration by
25%. Tracing all functions (instead of not tracing any function) had roughly 50% overhead during the
same benchmark. Most workloads spend much less time in the kernel than SDET, and more time in user
mode, which means normally ktracer’s overhead is much lower than this extreme. In the following
command:
# ktracer -r nTopFuncs
ktracer removes a number nTopFuncs of the most frequently encountered trace points. Doing so can be
quite effective in reducing the overhead of ktracer. To reiterate, the overhead strongly depends on how
frequently the _traced_ kernel functions are called.
Options Chart
ktracer supports the following command-line options. They are summarized here and described in
detail in the OPTION DETAILS section.
2 Hewlett-Packard Company − 2 − HP-UX 11i Version 3: September 2010