stackcount(8)
π stackcount(8) π
(System Manager's Manual, bestie, it's literally giving official docs π)
β¨ NAME β¨
okay so stackcount is the tool that counts function calls along with their whole stack traces π₯ It runs on Linux eBPF/bcc, so yes, it's very modern and very fast.
π SYNOPSIS π
stackcount [-h] [-p PID] [-c CPU] [-i INTERVAL] [-D DURATION] [-T]
[-r] [-s] [-P] [-K] [-U] [-v] [-d] [-f] [--debug] pattern
π¦ DESCRIPTION π¦
okay this is the main character of the whole page π
stackcount traces functions and frequency counts them along with their entire stack trace, kernel stack and user stack. The summarizing happens in-kernel for efficiency, which means higher frequency events are actually studiable now π The output is a list of unique stack traces along with how many times each one occurred. Kernel and user functions are covered, and so are kernel tracepoints and USDT tracepoints β¨
The pattern is a string with optional * wildcards, kind of like file globbing πΈ If you'd rather use regular expressions, just throw in the -r option π§
β οΈ bestie, this tool only works on Linux 4.6+. Stack traces come from the newBPF_STACK_TRACEAPIs. For kernels older than 4.6, go check the version undertools/oldinstead π
π§ REQUIREMENTS π§
You need CONFIG_BPF and bcc π«Ά
π OPTIONS π
-hβ Prints the usage message. Basically the cheat sheet π-rβ Lets the search pattern use regular expressions. By default you only get"*"wildcards, so this one unlocks the good stuff π-sβ Shows address offsets π-Pβ Displays stacks separately for each process π-Kβ Shows the kernel stack only π₯-Uβ Shows the user stack only πΈ-Tβ Adds a timestamp to interval output β-vβ Shows raw addresses π¦-dβ Prints a delimiter (--) between the kernel and user stacks, so they don't get mixed up π«Ά--debugβ Prints the source of the BPF program when it loads. This is for debugging purposes, so it's a dev-girl move π§-i intervalβ Sets the summary interval, in seconds β°-D durationβ Sets the total duration of the trace, in seconds β³-fβ Folded output format π-p PIDβ Traces this process ID only (filtered in-kernel) π―-c CPUβ Traces this CPU only (filtered in-kernel) πpatternβ A function name or a search pattern. It can include wildcards ("*"), and if you use-r, it can include regular expressions too π
π EXAMPLES π
okay here's the fun part, the examples are literally so good π
- Count kernel and user stack traces for
submit_bio():# stackcount submit_bio - Count stacks with a delimiter for
submit_bio():# stackcount -d submit_bio - Count the kernel stack trace only for
submit_bio():# stackcount -K submit_bio - Count the user stack trace only for
submit_bio():# stackcount -U submit_bio - Count stack traces for
ip_output():# stackcount ip_output - Show symbol offsets:
# stackcount -s ip_output - Show offsets and raw addresses (verbose):
# stackcount -sv ip_output - Count stacks for kernel functions matching
tcp_send*:# stackcount 'tcp_send*' - Same as the previous one, but with regular expressions:
# stackcount -r '^tcp_send.*' - Output every 5 seconds, with timestamps:
# stackcount -Ti 5 ip_output - Only count stacks when PID 185 is on-CPU:
# stackcount -p 185 ip_output - Only count stacks for CPU 1:
# stackcount -c 1 put_prev_entity - Count user stacks for dynamic heap allocations with
mallocin PID 185:# stackcount -p 185 c:malloc - Count user stacks for thread creation (USDT tracepoint) in PID 185:
# stackcount -p 185 u:pthread:pthread_create - Count stacks for context switch events using a kernel tracepoint:
# stackcount t:sched:sched_switch
π OVERHEAD π
This one is lowkey the most impressive part β¨ It summarizes unique stack traces in-kernel, so it can trace a higher rate of function calls than methods that post-process in user space. Stack trace data only gets copied to user space when the output is printed, which usually happens just once π«Ά The stack walking also runs in an optimized kernel code path thanks to the new BPF_STACK_TRACE table APIs, which should be more efficient than the manual walker in the eBPF tracer that older versions of this script used π₯ With that in mind, call rates under 10,000/sec should incur negligible overhead. Still, test before production use, no cap π You can also use funccount to check function call rates first π
πΊοΈ SOURCE πΊοΈ
This one comes from bcc π
https://github.com/iovisor/bcc
Also look in the bcc distribution for a companion _examples.txt file with example usage, output, and commentary for this tool π
π» OS π»
Linux π§
π§ͺ STABILITY π§ͺ
π§ Unstable, it's still in development. Be careful, bestie π
π AUTHOR π
Brendan Gregg and Sasha Goldshtein π
π SEE ALSO π
stacksnoop(8), funccount(8) π¦
Okay that's the whole page, bestie π It's a User Commands manual page dated 2016-01-14, for stackcount(8), so now you're officially a stack-counting queen πβ¨
π¦ where this page comes from
- debian bookworm: bpfcc-tools 0.26.0+ds-1 Β· Apache-2.0
- debian trixie: bpfcc-tools 0.31.0+ds-7 Β· Apache-2.0
- ubuntu jammy: bpfcc-tools 0.18.0+ds-2 Β· Apache-2.0
- ubuntu noble: bpfcc-tools 0.29.1+ds-1ubuntu7 Β· Apache-2.0
- ubuntu questing: bpfcc-tools 0.31.0+ds-7ubuntu2 Β· Apache-2.0
- ubuntu resolute: bpfcc-tools 0.35.0+ds-1ubuntu2 Β· Apache-2.0
- ubuntu stonking: bpfcc-tools 0.35.0+ds-1ubuntu4 Β· Apache-2.0
- π girlified by anthropic/claude-haiku-5.5 on : a language model's rewrite of the original, under its terms