Stop ftrace from stealing your cycles while you hunt for syscall latency

Technical Briefing | 8/14/2026

Most of us eventually reach for ftrace when the logs aren’t telling us the whole story. You enable a function tracer, the system load climbs, and suddenly the latency you were trying to diagnose disappears because the overhead is masking the very thing you’re investigating. It’s a classic observer effect that has bit me in prod more times than I care to admit.

Stop burning CPU on broad event capture

The trap is enabling global tracing or wide filter sets. When you define a filter for a specific process ID or function, you’re not just narrowing the data, you’re reducing the amount of context-switching the tracer does. But even then, ftrace can easily overwhelm your buffers if you aren’t careful. I prefer using trace_pipe with specific filters applied before the tracer starts.

echo 0 > /sys/kernel/debug/tracing/tracing_on
echo 1234 > /sys/kernel/debug/tracing/set_ftrace_pid
echo function_graph > /sys/kernel/debug/tracing/current_tracer
echo 1 > /sys/kernel/debug/tracing/tracing_on

• Always set your pid filter before turning the tracer on to avoid logging noise
• Keep buffer size small if you are running on a machine already under memory pressure
• Check /sys/kernel/debug/tracing/dropped if you suspect you are losing data due to slow consumption

If you’re still seeing system degradation, it’s time to stop looking at the full call graph and switch to kprobes with a dedicated eBPF tool like bpftrace. You get the same level of visibility without the heavy lifting ftrace does to format that string data for your shell. Next time the latency spike happens, keep the trace session short and targeted.