接前一篇文章：BCC源码内容概览（3）
本文参考官网中的Contents部分的介绍。
BCC源码根目录的文件，其中一些是同时包含C和Python的单个文件，另一些是.c和.py的成对文件，还有一些是目录。
跟踪（Tracing）
examples目录下的文件：
- examples/tracing/urandomread.py
一个内核跟踪点示例，它跟踪random:urandom_read。
bcc/examples/tracing/urandomread_example.txt文件内容如下：
Examples of urandomread.py, the Linux eBPF/bcc version.
To demonstrate this, the following workload was issued:
# dd if=/dev/urandom of=/dev/null bs=1k count=5
While urandomread.py was tracing in another session:
# ./urandomread.py
TIME(s) COMM PID GOTBITS
22592556.392825000 dd 14228 8192
22592556.392949000 dd 14228 8192
22592556.393068999 dd 14228 8192
22592556.393183999 dd 14228 8192
22592556.393298000 dd 14228 8192
The GOTBITS of 8192 matches the workload of 1 Kbyte (8 Kbit) reads.
This program was really written as a simple example of tracing a tracepoint.- examples/tracing/vfsreadlat.py和examples/tracing/vfsreadlat.c
VFS读取延迟分布。
bcc/examples/tracing/vfsreadlat_example.txt文件内容如下：
Demonstrations of vfsreadlat.py, the Linux eBPF/bcc version.
This example traces the latency of vfs_read (time from call to return), printing
it as a histogram distribution. By default, output is every five seconds:
# ./vfsreadlat.py
Tracing... Hit Ctrl-C to end.
usecs : count distribution
0 -> 1 : 4457 |*************************************+|
2 -> 3 : 447 |*** |
4 -> 7 : 2059 |***************** |
8 -> 15 : 1179 |********** |
16 -> 31 : 63 | |
32 -> 63 : 0 | |
64 -> 127 : 2 | |
128 -> 255 : 0 | |
256 -> 511 : 3 | |
512 -> 1023 : 1 | |
1024 -> 2047 : 3 | |
2048 -> 4095 : 2 | |
4096 -> 8191 : 0 | |
8192 -> 16383 : 0 | |
16384 -> 32767 : 0 | |
32768 -> 65535 : 0 | |
65536 -> 131071 : 4 | |
131072 -> 262143 : 2 | |
262144 -> 524287 : 0 | |
524288 -> 1048575 : 4 | |
^C
usecs : count distribution
0 -> 1 : 241 |*************************************+|
2 -> 3 : 17 |** |
4 -> 7 : 2 | |
8 -> 15 : 4 | |
16 -> 31 : 2 | |
32 -> 63 : 0 | |
64 -> 127 : 1 | |
128 -> 255 : 0 | |
256 -> 511 : 1 | |
512 -> 1023 : 1 | |
1024 -> 2047 : 0 | |
2048 -> 4095 : 1 | |
4096 -> 8191 : 0 | |
8192 -> 16383 : 0 | |
16384 -> 32767 : 0 | |
32768 -> 65535 : 0 | |
65536 -> 131071 : 0 | |
131072 -> 262143 : 0 | |
262144 -> 524287 : 0 | |
524288 -> 1048575 : 1 | |
These examples show outliers in the 524 - 1048 milliseconds range. Since
vfs_read() will catch many types of events, this could be anything including
keystroke latency on ssh sessions. Further drilling with bcc will be necessary
to identify more details.
Full usage:
# ./vfsreadlat.py -h
USAGE: ./vfsreadlat.py [interval [count]]- examples/tracing/kvm_hypercall.py
KVM entry、exit和hypercall的条件静态内核跟踪点。
bcc/examples/tracing/kvm_hypercall.txt文件内容如下：
Demonstrations of kvm_hypercall.py, showing eBPF/bcc based hypercall analysis
This example demonstrates how we can statefully save static tracepoint
events based on conditions being met for other events with which they are
associated. Here, we wish to record kvm_exit and kvm_entry events which are
linked to the kvm_hypercall event. We are interested in kvm_exit with exit
reason as VMCALL (18). This may be useful to analyze latency caused by a
hypercall itself.
To test this, while the python script is run, induce a hypercall from a
guest based on the following example:
https://gist.github.com/abenbachir/344822b5ba9fc5ac384cdec3f087e018
# ./kvm_hypercall.py
TIME(s) COMM PID MESSAGE
2445.577087000 CPU 0/KVM 8896 KVM_EXIT exit_reason : 18
2445.577122000 CPU 0/KVM 8896 HYPERCALL nr : 0
2445.577129000 CPU 0/KVM 8896 KVM_ENTRY vcpu_id : 0
2445.577136000 CPU 0/KVM 8896 KVM_EXIT exit_reason : 18
2445.577145000 CPU 0/KVM 8896 HYPERCALL nr : 1
2445.577149000 CPU 0/KVM 8896 KVM_ENTRY vcpu_id : 0
2445.577155000 CPU 0/KVM 8896 KVM_EXIT exit_reason : 18
2445.577160000 CPU 0/KVM 8896 HYPERCALL nr : 2
2445.577164000 CPU 0/KVM 8896 KVM_ENTRY vcpu_id : 0
2445.577170000 CPU 0/KVM 8896 KVM_EXIT exit_reason : 18
2445.577175000 CPU 0/KVM 8896 HYPERCALL nr : 3
2445.577179000 CPU 0/KVM 8896 KVM_ENTRY vcpu_id : 0
2445.577185000 CPU 0/KVM 8896 KVM_EXIT exit_reason : 18
2445.577190000 CPU 0/KVM 8896 HYPERCALL nr : 4
2445.577194000 CPU 0/KVM 8896 KVM_ENTRY vcpu_id : 0
This output shows a sequence of exit -> hypercall -> entry where the
exit_reason was VMCALL.