funcgraph(8) | System Manager's Manual | funcgraph(8) |
funcgraph - trace kernel function graph, showing child function calls and times. Uses Linux ftrace.
funcgraph [-aCDhHPtT] [-m maxdepth] [-p PID] [-L TID] [-d secs] funcstring
This is an exploratory tool that shows the graph of child function calls for a given kernel function. This can cost moderate overhead to execute, and should only be used to understand kernel behavior before using other, lower overhead tools. This is a proof of concept using Linux ftrace capabilities on older kernels.
The output format is the same as the ftrace function graph trace format, described in the kernel source under Documentation/trace/ftrace.txt. Note that the output may be shuffled when different CPU buffers are read; check the CPU column for changes, or include timestamps (-t) and post sort.
The "-d duration" mode leaves the trace data in the kernel buffer, and only reads it at the end. If the trace data is large, beware of exhausting buffer space (/sys/kernel/debug/tracing/buffer_size_kb) and losing data.
Also beware of feedback loops: tracing tcp* functions over an ssh session, or writing ext4* functions to an ext4 file system. For the former, tcp trace data could be redirected to a file (as in the usage message). For the latter, trace to the screen or a different file system.
WARNING: This uses dynamic tracing of kernel functions, and could cause kernel panics or freezes. Test, and know what you are doing, before use. Also see the OVERHEAD section.
Since this uses ftrace, only the root user can use this tool.
FTRACE CONFIG, which you may already have enabled and available on recent kernels.
The ftrace buffer has a fixed size per-CPU (see /sys/kernel/debug/tracing/buffer_size_kb). If you think events are missing, try increasing that size.
The output format depends on the kernel version, and headings can be printed using -H. The format is the same as the ftrace function trace format, described in the kernel source under Documentation/trace/ftrace.txt.
Typical fields are:
If the trace output begins with some returns that lack entries, their durations may not be trusted. This is usually only the case for the first dozen or so lines.
This tool causes moderate to high overheads. Use with caution for exploratory purposes, then switch to lower overhead techniques based on findings. It's expected that the kernel will run at least 50% slower while this tool is running -- even while no output is being generated. This is because ALL kernel functions are traced, and filtered based on the function of interest. When output is generated, it can generate many lines quickly depending on the traced event. Such data will cause performance overheads. This also works without buffering by default, printing function events as they happen (uses trace_pipe), context switching and consuming CPU to do so. If needed, you can try the "-d secs" option, which buffers events instead, reducing overhead. If you think the buffer option is losing events, try increasing the buffer size (buffer_size_kb).
It's a good idea to use funccount(8) first, which is lower overhead, to help you select which functions you may want to trace using funcgraph(8).
This is from the perf-tools collection:
Also look under the examples directory for a text file containing example usage, output, and commentary for this tool.
Linux
Unstable - in development.
Brendan Gregg
2014-07-29 | USER COMMANDS |