一、概述
Ftrace有剖析器和跟踪器。剖析器提供统计摘要，如激素胡和直方图；而跟踪器提供每一个事件的细节。
Ftrace剖析器列表：
| 剖析器 | 描述 |
|---|---|
| function | 内核函数统计分析 |
| kprobe profiler | 启用的kprobe计数器 |
| uprobe profiler | 启用的uprobe计数器 |
| hist trigger | 时间的自定义直方图 |
Ftrace事件跟踪器：
| 跟踪器 | 描述 |
|---|---|
| function | 内核函数调用跟踪器 |
| tracepoints | 内核静态检测时间跟踪器 |
| kprobes | 内核动态检测时间跟踪器 |
| uprobes | 用户级动态检测时间跟踪器 |
| function_graph | 内核函数跟踪，通过自调用的层次图展示 |
| wakeup | 测量CPU调度最大延迟 |
| wakeup_rt | 测量实时（RT）任务的最大CPU调度延迟 |
| irqsoff | 用代码位置和延迟跟踪IRQ关闭时间（中断禁用延迟） |
| preetmptoff | 跟踪有代码路径和延迟事件 |
| preetmptirgsoff | 一个结合了irqoff和preemptoff的跟踪器 |
| blk | 块IO跟踪器 |
| hwlat | 硬件延迟跟踪器：可以检测外部扰动（虚拟化）导致的延迟 |
| mmiotrace | 跟踪一个模块对硬件的调用 |
| nop | 一个特殊的跟踪器，可以禁用其他跟踪器 |
| 通过下面的方法可以查看目前你的内核版本可用的ftrace跟踪器： |
root@jian:~# cat /sys/kernel/tracing/available_tracers
hwlat blk mmiotrace function_graph wakeup_dl wakeup_rt wakeup function nop
二、tracefs
Ftrace最初是debugfs文件系统的一部分，知道它被拆分成自己的tracefs。使用Ftrace功能的接口是tracefs文件系统，它应该被挂载在/sys/kernel/tracing上。例如，用过以下方式可以使用：
mount -t tracefs tracefs /sys/kernel/tracing
请注意，如果tracefs 挂载失败，可能是由于你的内核在构建时没有配置Ftrace选项：CONFIG_FTRACE等。
一旦挂载了tracefs ，可以从目录中看到控制文件和输出文件：
root@jian:/sys/kernel/tracing# ls
available_events max_graph_depth stack_max_size
available_filter_functions options stack_trace
available_tracers per_cpu stack_trace_filter
buffer_percent printk_formats synthetic_events
buffer_size_kb README timestamp_mode
buffer_total_size_kb saved_cmdlines trace
current_tracer saved_cmdlines_size trace_clock
dynamic_events saved_tgids trace_marker
dyn_ftrace_total_info set_event trace_marker_raw
enabled_functions set_event_notrace_pid trace_options
error_log set_event_pid trace_pipe
events set_ftrace_filter trace_stat
free_buffer set_ftrace_notrace tracing_cpumask
function_profile_enabled set_ftrace_notrace_pid tracing_max_latency
hwlat_detector set_ftrace_pid tracing_on
instances set_graph_function tracing_thresh
kprobe_events set_graph_notrace uprobe_events
kprobe_profile snapshot uprobe_profile
下面列表标明了关键文件和目录的作用：
| 跟踪器 | 读写 | 描述 |
|---|---|---|
| available_events | 只读 | 列出了当前内核中可用的跟踪事件 |
| available_filter_functions | 只读 | 列出当前内核中可用于函数过滤的函数，用于设置过滤器 |
| available_tracers | 只读 | 列出了当前内核中可用的跟踪器 |
| buffer_size_kb | 读写 | 查看和修改每个CPU缓冲区的大小 |
| buffer_total_size_kb | 只读 | 查看内核跟踪缓冲区的总大小，只读 |
| current_tracer | 读写 | 显示出当前正在使用的跟踪器 |
| dynamic_events | 读写 | 在运行时动态管理内核跟踪事件，可以添加、移除或查看跟踪事件 |
| enabled_functions | 读写 | 用于查看当前启用的函数跟踪事件 |
| error_log | 只读 | 查看内核跟踪中的错误日志和警告信息。当进行内核跟踪时，可能会发生一些问题或警告记录在此 |
| events/ | 目录 | 事件跟踪器的控制文件：tracepoint、kprobe、uprobe |
| free_buffer | 只写 | 用于清空内核跟踪缓冲区，释放已使用的跟踪数据。 |
| function_profile_enabled | 读写 | 开启和关闭函数剖析器，用于性能分析。0：未启用；1：启用 |
| hwlat_detector/ | 目录 | 内核中的一个硬件延迟检测器的设置目录 |
| kprobe_events | 读写 | 创建/追加/删除/显示内核动态事件 |
| kprobe_profile | 只读 | 用于读取Kprobe事件的统计结果 |
| max_graph_depth | 读写 | 用于设置函数图跟踪的最大深度 |
| options/ | 目录 | 用于设置和配置跟踪选项。该目录下包含了一系列的文件，这些文件代表了不同的跟踪选项，可以通过读写这些文件来启用、禁用或调整相应的跟踪功能和参数。 |
| per_cpu/ | 目录 | 在Linux内核中用于存储和管理每个CPU的跟踪信息 |
| set_event | 读写 | 在这个文件中，你可以为特定事件设置跟踪选项 |
| set_event_notrace_pid | 读写 | 设置指定事件的不跟踪进程PID |
| set_event_pid | 读写 | 在这个文件中，你可以为特定事件设置跟踪的进程ID掩码 |
| set_ftrace_filter | 读写 | 允许你设置一个过滤器，只跟踪符合特定条件的事件。 |
| set_ftrace_notrace | 读写 | 通过写入特定函数名到这个文件，可以阻止这些函数被跟踪。 |
| set_ftrace_notrace_pid | 读写 | 用于设置指定进程PID的Ftrace非跟踪。 |
| set_ftrace_pid | 读写 | 用于设置需要进行Ftrace跟踪的进程PID |
| set_graph_function | 读写 | 用于配置函数图跟踪，允许你跟踪函数之间的调用关系 |
| set_graph_notrace | 读写 | 通过写入特定函数名到这个文件，可以阻止这些函数被图跟踪 |
| timestamp_mode | 只读 | 用于设置事件跟踪的时间戳模式 |
| trace | 读写 | 用于读取当前跟踪信息。 |
| trace_clock | 读写 | 用于设置跟踪事件的时钟类型 |
| trace_options | 读写 | 用于设置 Ftrace 的全局跟踪选项 |
| trace_pipe | 只读 | 通过读取这个文件，你可以获得连续的跟踪输出，而无需轮询trace文件。 |
| trace_stat/ | 目录 | 函数剖析器的结果输出，该目录下每一个文件记录着一个cpu |
| tracing_cpumask | 读写 | 设置 Ftrace 的 CPU 跟踪掩码，即选择在哪些 CPU 上进行跟踪。 |
| tracing_max_latency | 读写 | 用于设置 Ftrace 的最大跟踪延迟，如果跟踪的延迟超过该值会被丢弃，保持系统性能 |
| tracing_on | 读写 | 控制内核跟踪是否启用 |
| tracing_thresh | 读写 | 用于设置 Ftrace 的事件过滤阈值，用于过滤那些执行时间短于该阈值的函数调用，从而减少跟踪数据的量。 |
| uprobe_events | 读写 | 创建/追加/删除/显示用户动态事件 |
| uprobe_profile | 只读 | 用于读取uprobe事件的统计结果 |
option目录下文件介绍：
| 选项 | 描述 |
|---|---|
| annotate | 用于设置是否在跟踪时显示函数的注释信息。 |
| bin | 二进制文件，用于设置跟踪选项。 |
| blk_cgname | 用于设置是否在块层级上跟踪 cgroup 名称。 |
| blk_cgroup | 用于设置是否跟踪块层级的 cgroup 信息。 |
| blk_classic | 用于设置是否使用经典的块跟踪方式。 |
| block | 用于设置是否跟踪块层级事件。 |
| context-info | 用于设置是否显示上下文信息。 |
| disable_on_free | 用于设置是否在释放内存时禁用跟踪。 |
| display-graph | 用于设置是否显示图形跟踪。 |
| event-fork | 用于设置是否在 fork 时跟踪事件。 |
| funcgraph-abstime | 用于设置函数图形跟踪的时间戳是否使用绝对时间。 |
| funcgraph-cpu | 用于设置函数图形跟踪的 CPU 属于哪个组。 |
| funcgraph-duration | 用于设置函数图形跟踪的显示时长。 |
| funcgraph-irqs | 用于设置是否跟踪中断服务例程。 |
| funcgraph-overhead | 用于设置是否显示函数图形跟踪的开销信息。 |
| funcgraph-overrun | 用于设置当跟踪缓冲区溢出时是否报告。 |
| funcgraph-proc | 用于设置是否在 /proc/<pid>/call_graph 文件中输出函数图形跟踪信息。 |
| funcgraph-tail | 用于设置函数图形跟踪的尾部显示。 |
| func-no-repeats | 用于设置是否在跟踪时避免函数重复跟踪。 |
| func_stack_trace | 用于设置是否在跟踪时显示函数调用栈信息。 |
| function-fork | 用于设置是否在 fork 时跟踪函数调用。 |
| function-trace | 用于设置是否跟踪指定的函数。 |
| graph-time | 用于设置显示函数图形跟踪时是否显示时间信息。 |
| hash-ptr | 用于设置是否显示哈希指针跟踪信息。 |
| hex | 用于设置是否显示十六进制跟踪信息。 |
| irq-info | 用于设置是否显示中断信息。 |
| latency-format | 用于设置跟踪延迟格式。 |
| markers | 用于设置是否启用内核标记跟踪。 |
| overwrite | 用于设置是否覆盖现有的跟踪缓冲区。 |
| pause-on-trace | 用于设置是否在跟踪时暂停运行。 |
| printk-msg-only | 用于设置是否只跟踪 printk 消息。 |
| print-parent | 用于设置是否显示父函数。 |
| raw | 用于设置是否显示原始跟踪信息。 |
| record-cmd | 用于设置记录跟踪信息的命令。 |
| record-tgid | 用于设置是否以线程组ID标识记录跟踪信息。 |
| sleep-time | 用于设置休眠时间。 |
| stacktrace | 用于设置是否显示堆栈跟踪。 |
| sym-addr | 用于设置符号地址的显示方式。 |
| sym-offset | 用于设置符号偏移的显示方式。 |
| sym-userobj | 用于设置是否显示用户定义的符号对象。 |
| test_nop_accept | 用于设置是否接受测试命令 nop。 |
| test_nop_refuse | 用于设置是否拒绝测试命令 nop。 |
| trace_printk | 用于设置是否启用 trace_printk() 输出。 |
| userstacktrace | 用于设置是否跟踪用户堆栈信息。 |
| verbose | 用于设置是否显示详细的跟踪信息。 |
Ftrace控制和输出文件都可以通过echo和cat来使用。这意味着ftrace的使用几乎没有外部的依赖。最初ftrace并不支持并发用户，current_tracer文件一次只能被设置为一个跟踪器，后来增加了对并发用户的支持，形式是可以在instances目录中使用mkdir创建实例。每一个实例都有独立的current_tracer和输出文件，这样子他就可以独立进行跟踪了。并发实例参考：
root@jian:/sys/kernel/tracing/instances# mkdir foo
root@jian:/sys/kernel/tracing/instances# cd foo/
root@jian:/sys/kernel/tracing/instances/foo# ls
available_tracers set_event trace_clock
buffer_percent set_event_notrace_pid trace_marker
buffer_size_kb set_event_pid trace_marker_raw
buffer_total_size_kb set_ftrace_filter trace_options
current_tracer set_ftrace_notrace trace_pipe
error_log set_ftrace_notrace_pid tracing_cpumask
events set_ftrace_pid tracing_max_latency
free_buffer snapshot tracing_on
options timestamp_mode
per_cpu trace三、Ftrace函数剖析器
函数剖析器提供了关于内核函数调用的统计数据，适合于研究哪些内核函数正在被使用，并确定哪些是最慢的。我经常使用函数剖析器，将它作为了解工作负载的内核代码执行情况的起点，主要是因为他很高效，开销相对较低。使用它，我可以使用更加昂贵的与独立事件跟踪来分析函数。他需要配置CONFIG_FUNCTION_PROFILER=y。
函数剖析器的工作原理是在每个函数的开头使用编译后的剖析调用。这种方法是基于编译器剖析器的工作方式的。比如，gcc4.6版本的-pg选项，他插入了__fentry__，为每一个函数调价调用，在不使用的使用这些调用会被快速的nop指令代替，只有需要的时候才切换到__fentry__调用。
1.查看剖析器启用状态：
root@jian:/sys/kernel/tracing# cat set_ftrace_filter
#### all functions enabled ####
root@jian:/sys/kernel/tracing# cat function_profile_enabled
0
这种情况表示函数剖析器还没有启用。
2.使用函数剖析器统计ext4开头的内核函数，并且查看cpu0的统计结果：
root@jian:/sys/kernel/tracing# echo 'ext4*' > set_ftrace_filter
root@jian:/sys/kernel/tracing# echo 1 > function_profile_enabled
root@jian:/sys/kernel/tracing# sleep 2
root@jian:/sys/kernel/tracing# echo 0 > function_profile_enabled
root@jian:/sys/kernel/tracing# cat trace_stat/function0 Function Hit Time Avg s^2-------- --- ---- --- ---ext4_bmap 3 7.970 us 2.656 us 4.980 us ext4_file_getattr 3 4.212 us 1.404 us 0.007 us ext4_iomap_begin 3 3.910 us 1.303 us 1.162 us ext4_map_blocks 3 1.704 us 0.568 us 0.226 us ext4_journal_commit_callback 1 0.961 us 0.961 us 0.000 us ext4_getattr 3 0.862 us 0.287 us 0.001 us ext4_set_iomap 3 0.675 us 0.225 us 0.015 us ext4_es_lookup_extent 3 0.588 us 0.196 us 0.016 us ext4_iomap_end 3 0.330 us 0.110 us 0.010 us ext4_process_freed_data 1 0.321 us 0.321 us 0.000 us
从trace_stat目录中读取配置文件的统计数据，改目录为每一个CPU保存了"function"文件。从function0读取到cpu0的统计数据。列中显示了函数名称、调用次数、函数总时间、平均时间和标准差。
在剖析过程中，会有少量的开销被添加到剖析函数中。如果set_ftrace_filter 为设置任何值，所有的内核函数都会被剖析，在使用剖析器前尽量使用函数过滤来限制开销。
四、Ftrace function跟踪器
函数跟踪器打印内核函数调用的每个事件的详细信息，并使用前面描述的函数剖析工具。这可以显示各种函数的顺序，基于时间戳的模式，以及可能对应的CPU上的进程名称和PID。函数跟踪的开销比函数剖析搞，因此跟踪是和与对调用不频繁的函数（每秒少于1000个调用）进行。我们可以在函数剖析的结果中找到调用函数的频率。
1.查看函数跟踪器启用状态：
root@jian:/sys/kernel/tracing# cat current_tracer
nop
root@jian:/sys/kernel/tracing#
我们可以看到当前的跟踪器是nop，一开始我们就提到了，这是一个特殊的跟踪器，可以禁用其他跟踪器。
2.使用function跟踪器跟踪vfs开头的函数：
root@jian:/sys/kernel/tracing# echo 0 > tracing_on
root@jian:/sys/kernel/tracing# echo 'vfs*' > set_ftrace_filter
root@jian:/sys/kernel/tracing# echo function > current_tracer
root@jian:/sys/kernel/tracing# echo 1 > tracing_on
root@jian:/sys/kernel/tracing# sleep 2
root@jian:/sys/kernel/tracing# echo 0 > tracing_on
root@jian:/sys/kernel/tracing# cat trace > /tmp/vfs_trace.log
root@jian:/sys/kernel/tracing# echo nop > current_tracer
root@jian:/sys/kernel/tracing# cat /tmp/vfs_trace.log
# tracer: function
#
# entries-in-buffer/entries-written: 6150/6150 #P:4
#
# _-----=> irqs-off/BH-disabled
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / _-=> migrate-disable
# |||| / delay
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
# | | | ||||| | |bash-2163 [002] ...2. 29204.893294: vfs_write <-ksys_writebash-2163 [002] ...2. 29204.893312: vfs_write <-ksys_writesudo-2161 [002] ...2. 29204.893339: vfs_read <-ksys_readsudo-2161 [002] ...2. 29204.893347: vfs_write <-ksys_writegnome-terminal--2137 [000] ...2. 29204.893590: vfs_write <-ksys_writegnome-terminal--2137 [000] ...2. 29204.893595: vfs_read <-ksys_readgnome-terminal--2137 [000] ...2. 29204.893598: vfs_read <-ksys_readgnome-terminal--2137 [000] ...2. 29204.893599: vfs_write <-ksys_writegnome-terminal--2137 [000] ...2. 29204.893606: vfs_read <-ksys_readgnome-shell-1322 [003] ...2. 29204.894071: vfs_write <-ksys_write我们可以看到跟踪vfs开头函数的结果。输出包括字段头和跟踪元数据。第一行的例子显示了一个名为bash，PID为2163的进程在cpu2上运行，调用了vfs_write函数，后面的ksys_write是调用来源。“ …2.”是irq-info带来的输出，表示中断相关的信息。
五、Ftrace function_graph跟踪器
function_graph跟踪器课打印出函数的调用图，器揭示了代码的流程。
下面对vfs_open函数使用function_graph跟踪器，显示其子函数的调用：
root@jian:/sys/kernel/tracing# echo 'vfs_open' > set_graph_function
root@jian:/sys/kernel/tracing# echo function_graph > current_tracer
root@jian:/sys/kernel/tracing# cat trace_pipe
root@jian:/sys/kernel/tracing# sleep 1
root@jian:/sys/kernel/tracing# cat trace > /tmp/vfs_open_trace.log
root@jian:/sys/kernel/tracing# echo nop > current_tracer
root@jian:/sys/kernel/tracing# cat /tmp/vfs_open_trace.log
# tracer: function_graph
#
# CPU DURATION FUNCTION CALLS
# | | | | | | |3) | vfs_open() {3) | do_dentry_open() {3) | path_get() {3) 0.091 us | mntget();3) 0.246 us | }3) 0.076 us | try_module_get();3) | security_file_open() {3) 0.081 us | hook_file_open();3) 0.084 us | apparmor_file_open();3) 0.080 us | __fsnotify_parent();3) 0.078 us | __fsnotify_parent();3) 0.738 us | }3) | ext4_file_open() {3) 0.077 us | ext4_sample_last_mounted();3) | fscrypt_file_open() {3) | dget_parent() {3) 0.071 us | __rcu_read_lock();3) 0.071 us | __rcu_read_unlock();3) 0.356 us | }3) | dput() {3) 0.068 us | __cond_resched();3) 0.069 us | __rcu_read_lock();3) 0.070 us | __rcu_read_unlock();3) 0.489 us | }3) 1.344 us | }3) 0.070 us | fsverity_file_open();3) | dquot_file_open() {3) 0.071 us | generic_file_open();3) 0.212 us | }3) 2.086 us | }3) | file_ra_state_init() {3) 0.070 us | inode_to_bdi();3) 0.218 us | }3) 3.902 us | }3) 4.116 us | }
六、ftrace hwlat
硬件延迟检测器（hwlat）是特殊用途跟踪器。它可以检测到外部硬件时间对CPU性能的干扰，否则内核和其他工具是看不到这些事件的。例如，系统管理中断SMI事件和虚拟机管理程序扰动（包括那些油吵闹的邻居引起的扰动）。
其工作原理是在禁用中断的情况下运行一个代码循环作为实验，测量循环每一个迭代所消耗的时间。这个循环每次在一个CPU上执行，并在它们之间轮换。每个CPU上最慢的循环会被打印出来，说明它超过了阈值（10微秒，可以通过tracing_thresh文件配置）。我们尝试一下：
root@jian:/sys/kernel/tracing# echo hwlat > current_tracer
root@jian:/sys/kernel/tracing#
root@jian:/sys/kernel/tracing# cat trace
# tracer: hwlat
#
# entries-in-buffer/entries-written: 6/6 #P:4
#
# _-----=> irqs-off/BH-disabled
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / _-=> migrate-disable
# |||| / delay
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
# | | | ||||| | |<...>-3439 [001] d.... 47106.432688: #1 inner/outer(us): 68/48 ts:1690510991.980173202 count:1612<...>-3439 [002] d.... 47107.444798: #2 inner/outer(us): 65/48 ts:1690510992.990531284 count:1312<...>-3439 [003] d.... 47108.468134: #3 inner/outer(us): 82/93 ts:1690510994.014977964 count:1929<...>-3439 [000] d.... 47109.493436: #4 inner/outer(us): 59/73 ts:1690510995.039183943 count:1480<...>-3439 [001] d.... 47110.515790: #5 inner/outer(us): 57/60 ts:1690510996.063654968 count:1664<...>-3439 [002] d.... 47111.539715: #6 inner/outer(us): 108/55 ts:1690510997.087995749 count:1654
jian@jian:~$ ps -aux |grep 3439
root 3439 49.1 0.0 0 0 ? S 10:23 0:58 [hwlatd]前面的进程名称、PID，CPU和时间戳就不细讲了，时间错后面有一个序号（#1、#2），然后是“inner/outer(us)”的数字，以及最后的时间戳。inner/outer的数字显示了循环内部的时间和到下一个循环迭代的代码逻辑时间（外部）。第一行显示一次迭代消耗了68微秒（内部）和48微秒（外部）。这远远超过了10微秒的阈值，并且是由于外部的扰动造成的。
hwlat具有可以配置的参数：循环运行的时间段称为宽度，运行一个宽度实验的时间称为窗口。在每个宽度期间，超过阈值（10微秒）的最慢迭代会被记录下来。这些参数可以通过/sys/kernel/tracing/hwlat_detector中的文件修改：宽度和窗口文件，他们使用微秒作为单位。
hwlat其实是一种微基准测试工具，而不是可观测工具，因为它执行的实验本身就会扰乱系统，他将使一个cpu在整个宽度期间处于繁忙状态，并且禁用中断。
七、ftrace hist
hist触发器允许在事件上创建自定义的直方图，这是另一种形式的统计摘要，允许计数按照一个或者多个组成部分进行分解。
我们试试使用hist触发器通过raw_syscalls:sys_enter跟踪点来计数系统调用数量，并提供按进程ID分类的直方图：
root@jian:/sys/kernel/tracing# echo 'hist:key=common_pid' > events/raw_syscalls/sys_enter/trigger
root@jian:/sys/kernel/tracing# sleep 2
root@jian:/sys/kernel/tracing# cat events/raw_syscalls/sys_enter/hist
# event histogram
#
# trigger info: hist:keys=common_pid:vals=hitcount:sort=hitcount:size=2048 [active]
#。。。
{ common_pid: 1857 } hitcount: 440
{ common_pid: 764 } hitcount: 591
{ common_pid: 2130 } hitcount: 615
{ common_pid: 1950 } hitcount: 682
{ common_pid: 1423 } hitcount: 840
{ common_pid: 1738 } hitcount: 1145
{ common_pid: 745 } hitcount: 1213
{ common_pid: 1767 } hitcount: 1566
{ common_pid: 1363 } hitcount: 1819
{ common_pid: 3978 } hitcount: 121650
{ common_pid: 3977 } hitcount: 187630Totals:Hits: 320268Entries: 36Dropped: 0
root@jian:/sys/kernel/tracing# echo '!hist:key=common_pid' > events/raw_syscalls/sys_enter/trigger
输出显示，PID为3977的进程在跟踪期间执行了187630次系统调用，也列出了其他PID的计数。最后几行显示了统计信息：写到哈希的次数（Hits），哈希中的条目（Entries），当前条目超过哈希大小时，写操作被丢弃的次数（Dropped）。如果发生了丢弃，可以在声明哈希表时增加它的大小；它的默认值是2048。
上面的例子使用的是common_pid这个字段，我们可以查看他的格式，使用其他字段作为他的哈希键值甚至使用多关键字段：
root@jian:/sys/kernel/tracing# cat events/raw_syscalls/sys_enter/format
name: sys_enter
ID: 349
format:field:unsigned short common_type; offset:0; size:2; signed:0;field:unsigned char common_flags; offset:2; size:1; signed:0;field:unsigned char common_preempt_count; offset:3; size:1;signed:0;field:int common_pid; offset:4; size:4; signed:1;field:long id; offset:8; size:8; signed:1;field:unsigned long args[6]; offset:16; size:48; signed:0;print fmt: "NR %ld (%lx, %lx, %lx, %lx, %lx, %lx)", REC->id, REC->args[0], REC->args[1], REC->args[2], REC->args[3], REC->args[4], REC->args[5]root@jian:/sys/kernel/tracing# echo 'hist:key=common_pid,id' > events/raw_syscalls/sys_enter/trigger
有时候结果太多，为了让测量的结果更加直观，可以为系统调用ID创建一个直方图，然后使用一个过滤器来匹配PID，还使用.syscall修饰器修饰系统调用ID，结果会很直观：
root@jian:/sys/kernel/tracing# echo 'hist:key=id.syscall if common_pid==2477' > events/raw_syscalls/sys_enter/trigger
root@jian:/sys/kernel/tracing# cat events/raw_syscalls/sys_enter/hist
# event histogram
#
# trigger info: hist:keys=id.syscall:vals=hitcount:sort=hitcount:size=2048 if common_pid==2477 [active]
#{ id: sys_pipe2 [293] } hitcount: 1
{ id: sys_setpgid [109] } hitcount: 1
{ id: sys_clone [ 56] } hitcount: 1
{ id: sys_fcntl [ 72] } hitcount: 1
{ id: sys_rt_sigreturn [ 15] } hitcount: 1
{ id: sys_wait4 [ 61] } hitcount: 2
{ id: sys_close [ 3] } hitcount: 2
{ id: sys_write [ 1] } hitcount: 6
{ id: sys_read [ 0] } hitcount: 7
{ id: sys_pselect6 [270] } hitcount: 7
{ id: sys_ioctl [ 16] } hitcount: 15
{ id: sys_rt_sigprocmask [ 14] } hitcount: 15
{ id: sys_rt_sigaction [ 13] } hitcount: 23Totals:Hits: 82Entries: 13Dropped: 0
直方图现在显示了一个PID的系统调用，.syscall修饰器已经包括了系统调用的函数名。我们还可以使用栈踪迹关键字来了解事件发生的代码路径，例如：
root@jian:/sys/kernel/tracing# echo 'hist:key=stacktrace' > events/raw_syscalls/sys_enter/trigger
这样子可以查看函数的堆栈。
