Ftrace使用及实现机制
版权声明：本文为本文为博主原创文章，转载请注明出处 https://www.cnblogs.com/wsg1100 如有错误，欢迎指正。
一、使用ftrace
ftrace 即function tracer，最初是用来 trace 内核中的函数，在 2008 年的时候被合入了 Linux 内核，当时的版本是 Linux2.6.x。现在 ftrace 的功能不仅仅是function tracer，更加丰富了，可观测内核很多信息。本文分为两个部分，第一部分介绍ftrace的使用，大部分来源于Linux内核ftrace文档，第二部分介绍ftrace的实现原理。
1.挂载
ftrace 的所有操作在 tracefs 这个虚拟文件系统中完成， tracefs 的挂载点在 /sys/kernel/debug/tracing 下：
# cat /proc/mounts | grep tracefs
tracefs /sys/kernel/debug/tracing tracefs rw,relatime 0 0
如果没有自动挂载，则需要手动挂载：
# mount -t tracefs /sys/kernel/debug/tracing
挂载后/sys/kernel/debug/tracing 目录下的文件如下：
# cd /sys/kernel/debug/tracing
# ls
available_events events README set_graph_function trace_marker_raw
available_filter_functions free_buffer saved_cmdlines set_graph_notrace trace_options
available_tracers function_profile_enabled saved_cmdlines_size snapshot trace_pipe
buffer_percent hwlat_detector saved_tgids stack_max_size trace_stat
buffer_size_kb instances set_event stack_trace tracing_cpumask
buffer_total_size_kb kprobe_events set_event_notrace_pid stack_trace_filter tracing_max_latency
current_tracer kprobe_profile set_event_pid synthetic_events tracing_on
dynamic_events max_graph_depth set_ftrace_filter timestamp_mode tracing_thresh
dyn_ftrace_total_info options set_ftrace_notrace trace uprobe_events
enabled_functions per_cpu set_ftrace_notrace_pid trace_clock uprobe_profile
error_log printk_formats set_ftrace_pid trace_marker
2. 关键文件介绍
tracefs 虚拟文件系统下的文件操作和我们常用的 Linux proc 和 sys 虚拟文件系统的操作差不多。通过对某个文件的 echo 操作，我们可以向内核的 ftrace 系统发送命令，然后 cat 某个文件得到 ftrace 的返回结果。
/sys/kernel/debug/tracing 目录各文件及作用如下，根据具体场景使用：
current_tracer：
设置或显示当前tracer配置。
available_tracers：
内核支持的tracer配置，内核编译时配置，将里面的配置写入current_tracer即设置设置当前trace功能。
tracing_on：
设置是否将trace写入tracer缓冲区，写0到该文件禁用trace写入缓冲区，写1启用，无论写0还是写1，内核trace都在运行，都有trace开销。
trace:
该文件以人类可读的格式保存跟踪的输出。注意，正在读取（打开）此文件时会暂时禁用跟踪。
trace_pipe:
输出与“trace”文件相同，但此文件应使用实时跟踪进行流式处理。从此文件读取将阻塞，直到检索到新数据。 与“trace”文件不同，此文件是消费者。 一旦从该文件读取数据，就会消耗该数据。 “trace”文件是静态的，如果跟踪器没有添加更多数据，则每次读取时都会显示相同的信息。 此文件在读取时不会禁用跟踪。
trace_options:
此文件允许用户控制上述输出文件之一中显示的数据量。
options:
这是一个目录，其中包含每个可用跟踪选项的文件（也在trace_options中）。 也可以通过将“1”或“0”分别写入带有选项名称的相应文件来设置或清除选项。
tracing_max_latency:
一些跟踪器记录了最大延迟。 例如，禁用中断的最长时间。此文件中保存最长时间。 最大跟踪也将得到优化，并通过trace显示。 如果延迟大于此文件中的值（以微秒为单位），则只会记录新的最大跟踪。
通过echo写入一个时间值，除非它大于此文件中的时间，否则不会记录任何延迟。
tracing_thresh:
只要延迟大于此文件中的数字，某些延迟跟踪器就会记录跟踪。仅当文件包含大于0的数字时才有效。（以微秒为单位）
buffer_size_kb：
这将设置或显示每个CPU缓冲区大小。 默认情况下，跟踪缓冲区的大小与每个CPU的大小相同。 显示的数字是CPU缓冲区的大小，而不是所有缓冲区的总大小。 跟踪缓冲区分配在一个内存页面（内核用于分配的内存块，通常为4 KB）。
buffer_total_size_kb:
这将显示所有跟踪缓冲区的总大小。
free_buffer:
用于释放缓冲区，让一个跟踪进程打开这个文件，当进程退出时，该文件的文件描述符将被关闭，这样，环形缓冲区将被“释放”。
tracing_cpumask:
这是一个掩码，用于指定跟踪的CPU。格式是表示CPU的十六进制字符串。
set_ftrace_filter:
set_ftrace_notrace:
这与set_ftrace_filter的效果相反。 此处添加的任何功能都不会被跟踪。 如果set_ftrace_filter和set_ftrace_notrace中都存在函数，则不会跟踪该函数。
set_ftrace_pid:
让函数跟踪器仅跟踪其PID在此文件中列出的线程。如果设置了“function-fork”选项，那么当该文件中列出PID的任务分fork时，子进程的PID将自动添加到该文件中，并且该子进程将被跟踪。 此选项还将导致退出的任务的PID从文件中删除。
set_event_pid:
此文件中列出的需要event跟踪的任务PID。注意，sched_switch和sched_wake_up还将跟踪此文件中列出的事件。如果要跟踪此文件中PID的任务的子进程，还需要启用“event-fork”选项。 任务退出时该文件内的PID将被删除。
set_graph_function:
函数图形跟踪器将跟踪此文件中列出的函数及其调用的函数。 （有关详细信息，请参阅“动态ftrace”部分）。
set_graph_notrace:
与set_graph_function类似，但在函数被命中时将禁用函数图形跟踪，直到它退出函数。这使得可以忽略由特定函数调用的跟踪函数。
max_graph_depth:
与函数图形跟踪器一起使用。 这是它将追溯到函数的最大深度。 将其设置为值1将仅显示从用户空间调用的第一个内核函数。
available_filter_functions:
这列出了ftrace已处理并可跟踪的功能。这些是可以传递给“set_ftrace_filter”或“set_ftrace_notrace”的函数名称。 （有关详细信息，请参阅下面的“动态ftrace”部分。）
dyn_ftrace_total_info:
此文件用于调试目的。 已转换为nops且可以跟踪的函数数。
enabled_functions:
function_profile_enabled:
设置后，它将启用具有功能跟踪器或功能图形跟踪器的所有功能。 它将保留被调用函数数量的直方图，如果配置了函数图形跟踪器，它还将跟踪这些函数所花费的时间。 直方图内容可以显示在文件中：
trace_stats/function<cpu>（function0，function1等）。
trace_stats:
包含不同跟踪统计信息的目录。
kprobe_events:
启用动态跟踪点。 请参阅kprobetrace.txt。
kprobe_profile:
动态跟踪点统计信息。 请参阅kprobetrace.txt。
printk_formats:
这适用于读取原始格式文件的工具。 如果环形缓冲区中的事件引用了一个字符串，则只有指向该字符串的指针被记录到缓冲区而不是字符串本身。 这可以防止工具知道该字符串是什么。 此文件显示字符串的字符串和地址，允许工具将指针映射到字符串。
saved_cmdlines:
除非事件专门保存任务comm，否则只有任务的pid记录在跟踪事件中。 Ftrace对通信进行pid映射缓存，以尝试显示事件的通信。 如果未列出comm的pid，则输出中将显示“<…>”。
如果选项“record-cmd”设置为“0”，则在录制期间不会保存任务通信。 默认情况下，它启用.
saved_cmdlines_size:
默认情况下，会保存128个通讯（请参阅上面的“saved_cmdlines”）。 要增加或减少缓存的通信量，请将要缓存的通信数回显到此文件中。
saved_tgids:
如果设置了“record-tgid”选项，则在每个调度上下文切换时，任务的任务组ID将保存在将线程的PID映射到其TGID的表中。 默认情况下，禁用“record-tgid”选项。
snapshot:
这将显示“Snapshot”缓冲区，还允许用户拍摄当前运行跟踪的快照。 有关详细信息，请参阅下面的“Snapshot”部分。
stack_max_size:
激活堆栈跟踪器时，将显示它遇到的最大堆栈大小。请参阅下面的“堆栈跟踪”部分。
stack_trace:
这将显示激活堆栈跟踪器时遇到的最大堆栈的堆栈跟踪跟踪。请参阅下面的“堆栈跟踪”部分。
stack_trace_filter:
这与“set_ftrace_filter”类似，但它限制了堆栈跟踪器将检查的功能。
trace_clock:
只要将事件记录到环形缓冲区中，就会添加“timestamp”。这个时间戳来自指定的时钟。默认情况下，ftrace使用“local”时钟。这个时钟非常快且严格按照cpu计算，但在某些系统上，它可能与其他CPU相比不是单调的。换句话说，本地时钟可能与其他CPU上的本地时钟不同步。
通常用于跟踪的时钟如下(带有方括号的时钟是有效的。)：
# cat trace_clock
[local] global counter uptime perf mono mono_raw boot x86-tsc
local：默认时钟，但可能不在CPU之间同步.
global：此时钟与所有CPU同步，但可能比本地时钟慢一点。
counter：这根本不是时钟，而是一个原子计数器。它逐个计数，但与所有CPU同步。当您需要准确了解不同CPU上相互发生的订单事件时，这非常有用。
uptime 这使用jiffies计数器，时间戳相对于启动后的时间。
perf: 这使得ftrace使用perf使用的相同时钟。最终perf将能够读取ftrace缓冲区，这将有助于交错数据。
x86-tsc:架构可以定义自己的时钟。例如，x86在此使用自己的TSC周期时钟。
ppc-tb:这使用powerpc时基寄存器值。这在CPU之间是同步的，并且如果已知tb_offset，还可以用于跨管理程序/来宾关联事件。
mono:这使用快速单调时钟（CLOCK_MONOTONIC），它是单调递增的，可以进行NTP速率调整。
mono_raw:这是原始的单调时钟（CLOCK_MONOTONIC_RAW），它是单调递增的，但不受任何速率调整和滴答，速率与硬件时钟源相同。
boot:这是启动时钟（CLOCK_BOOTTIME），基于快速单调时钟，但也占用了挂起时间。由于时钟访问被设计用于在挂起路径中进行跟踪，因此如果在更新快速单声道时钟之前计算挂起时间之后访问时钟，则可能产生一些副作用。在这种情况下，时钟更新似乎比通常情况稍早发生。
要设置时钟，只需将时钟名称回显到此文件中即可。
echo global> trace_clock
trace_marker:
这是一个非常有用的文件，用于将用户空间与内核中发生的事件同步。 将字符串写入此文件将写入ftrace缓冲区。在应用程序中，在应用程序启动时打开此文件,并仅引用文件的文件描述符非常有用。
void trace_write(const char *fmt, ...)
{
va_list ap;
char buf[256];
int n;
if (trace_fd < 0)
return;
va_start(ap, fmt);
n = vsnprintf(buf, 256, fmt, ap);
va_end(ap);
write(trace_fd, buf, n);
}
// 开始:
trace_fd = open("trace_marker", WR_ONLY);
trace_marker_raw:
这与上面的trace_marker类似，但是用于将二进制数据写入其中，其中可以使用工具来解析来自trace_pipe_raw的数据。
uprobe_events:
在程序中添加动态跟踪点。 请参阅uprobetracer.txt
uprobe_profile:
Uprobe统计。 请参阅uprobetrace.txt
instances:
这是一种制作多个跟踪缓冲区的方法，可以在不同的缓冲区中记录不同的事件。 请参阅下面的“实例”部分。
events:
这是跟踪事件目录。 它包含已编译到内核中的事件跟踪点（也称为静态跟踪点）。 它显示了存在哪些事件跟踪点以及它们如何按系统分组。 各种级别都有“启用”文件，可以在写入“1”时启用跟踪点。有关更多信息，请参阅events.txt。
set_event:
通过在事件中回显到此文件，将启用该事件。有关更多信息，请参阅events.txt。
available_events:
可以在跟踪中启用的事件列表,有关更多信息，请参阅events.txt。
hwlat_detector:
硬件延迟检测器的目录。请参阅下面的“硬件延迟检测器”部分。
per_cpu:
这是一个包含跟踪per_cpu信息的目录。
per_cpu/cpu0/buffer_size_kb:
ftrace缓冲区定义为per_cpu。 也就是说，每个CPU都有一个单独的缓冲区，允许以原子方式完成写入，并且不受cache bouncing的影响。 这些缓冲区可能有不同大小的缓冲区 此文件类似于buffer_size_kb文件，但它仅显示或设置特定CPU的缓冲区大小。 （这里是cpu0）。
per_cpu/cpu0/trace:
这类似于“跟踪”文件，但它只显示特定于CPU的数据。 如果写入，它只清除特定的CPU缓冲区。
per_cpu/ CPU0/ trace_pipe
这类似于“trace_pipe”文件，并且是一个消耗读取，但它只显示（和使用）特定于CPU的数据。
per_cpu/ CPU0/ trace_pipe_raw
对于可以解析ftrace环形缓冲区二进制格式的工具，trace_pipe_raw文件可用于直接从环形缓冲区中提取数据。 通过使用splice（）系统调用，缓冲区数据可以快速传输到文件或服务器正在收集数据的网络。与trace_pipe一样，这是一个消费者，其中多次读取将始终产生不同的数据。
per_cpu/ CPU0/snapshot
这类似于主“快照”文件，但只会对当前CPU（如果支持）进行快照。 它仅显示给定CPU的快照内容，如果写入，则仅清除此CPU缓冲区。
per_cpu/cpu0/snapshot_raw:
与trace_pipe_raw类似，但将从给定CPU的快照缓冲区中读取二进制格式。
per_cpu/cpu0/stats:
这会显示有关环形缓冲区的某些统计信息：
entries：仍在缓冲区中的事件数。
overrun: 缓冲区已满时由于覆盖而丢失的事件数。
commit overrun：应该始终为零。
如果在嵌套事件（环形缓冲区重入）中发生了如此多的事件，则它会被设置，它会填充缓冲区并开始丢弃事件。
bytes:字节实际读取（未覆盖）。
oldest event ts:缓冲区中最旧的时间戳
now ts:当前时间戳
dropped events:由于覆盖选项关闭而导致事件丢失。
read events:读取的事件数.
3.current_tracer列表
以下是可配置的current_tracer列表：
function
函数调用跟踪器来跟踪所有内核函数。
**function_graph **
与函数跟踪器类似，除了函数跟踪器探测其条目上的函数，而函数图形跟踪器跟踪函数的进入和退出。 然后它提供了绘制类似于C代码源的函数调用图的能力。
blk
块跟踪器。 blktrace用户应用程序使用的跟踪器。
hwlat
硬件延迟跟踪器用于检测硬件是否产生任何延迟。 请参阅下面的“硬件延迟检测器”部分。
irqsoff
跟踪禁用中断的区域并以最长的最大延迟保存跟踪。请参阅tracing_max_latency。 记录新的最大值时，它将替换旧的迹线。 最好在启用延迟格式选项的情况下查看此跟踪，这在选择跟踪器时会自动发生。
preemptoff
与irqsoff类似，但跟踪并记录禁用抢占的时间。
preemptirqsoff
与irqsoff和preemptoff类似，但跟踪并记录禁用irqs和/或抢占的最大时间。
wakeup
跟踪并记录最高优先级任务在被唤醒后进行调度所需的最大延迟。按照普通开发人员的预期跟踪所有任务。
wakeup_rt
跟踪并记录仅执行RT任务所需的最大延迟（如当前“唤醒”所做的那样）。 这对那些对RT任务的唤醒时间感兴趣的人很有用。
wakeup_dl
跟踪并记录SCHED_DEADLINE任务被唤醒所需的最大延（如wakeup和wakeup_rt）。
mmiotrace
用于跟踪二进制模块的特殊跟踪器。 它将跟踪模块对硬件的所有调用。 它所写的所有内容以及从I / O中读取的内容。
branch
在跟踪内核中可能/不可能的调用时，可以配置此跟踪器。 它将追踪一个可能的和不太可能的分支何时被击中，以及它在预测正确时是否正确。
nop
这是“无痕迹”的示踪剂。 要从跟踪中删除所有跟踪器，只需将“nop”写道到current_tracer。
4.trace输出示例
4.1 trace输出格式
下面简单了解下ftrace的使用。ftrace的输出结果都可以通过 cat trace 这个命令得到，在缺省状态下 ftrace 的 tracer 是 nop，也就是 ftrace 什么都不做。因此，我们从cat trace中也看不到别的，只是显示了 trace 输出格式。
root@work-machine:/sys/kernel/debug/tracing# cat trace
# tracer: nop
#
# entries-in-buffer/entries-written: 0/0 #P:8
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / _-=> migrate-disable
# |||| / delay
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
# | | | ||||| | |
这里以function tracer为例，function tracer 只是 ftrace 最基本的功能，是我们平常调试 Linux 内核问题时最常用到的功能，执行 echo function > current_tracer 来告诉 ftrace，我要启用 function tracer.
root@work-machine:/sys/kernel/debug/tracing# cat current_tracer
nop
root@work-machine:/sys/kernel/debug/tracing# cat available_tracers
hwlat blk mmiotrace function_graph wakeup_dl wakeup_rt wakeup function nop
root@work-machine:/sys/kernel/debug/tracing# echo function > current_tracer
root@work-machine:/sys/kernel/debug/tracing# cat current_tracer
function
在启动了 function tracer 之后，我们再查看一下 trace 的输出。这时候我们就会看到大量的输出，每一行的输出就是当前内核中被调用到的内核函数。
root@work-host:/sys/kernel/debug/tracing# cat trace
# tracer: function
#
# entries-in-buffer/entries-written: 358096/10552611 #P:8
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / _-=> migrate-disable
# |||| / delay
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
# | | | ||||| | |
<idle>-0 [000] *.... 46719.316253: handle_irq_pipelined_prepare <-arch_pipeline_entry
<idle>-0 [000] *.~.. 46719.316289: arch_handle_irq <-arch_pipeline_entry
<idle>-0 [000] *.~.. 46719.316289: generic_pipeline_irq_desc <-arch_handle_irq
<idle>-0 [000] *.~.. 46719.316289: handle_fasteoi_irq <-generic_pipeline_irq_desc
<idle>-0 [000] *.~.. 46719.316290: irq_may_run <-handle_fasteoi_irq
<idle>-0 [000] *.~.. 46719.316290: handle_oob_irq <-handle_fasteoi_irq
<idle>-0 [000] *.~.. 46719.316290: mask_irq.part.0 <-handle_fasteoi_irq
<idle>-0 [000] *.~.. 46719.316290: mask_ioapic_irq <-mask_irq.part.0
<idle>-0 [000] *.~.. 46719.316294: io_apic_sync <-mask_ioapic_irq
......
第2行标题及tracer的配置为function (跟踪函数)
第4行 显示缓冲区中的事件数以及写入的条目总数。
358096
/
10552611
358096/10552611
358096/10552611,由于缓冲区填满而丢失的条目数（
10552611
−
358096
=
10
,
194
,
515
10552611- 358096=10,194,515
10552611−358096=10,194,515事件丢失），接着是处理器数量：8
下面是记录的事件的内容：任务名称“",它的PID为：0，运行在”000“号CPU上，后面是延迟的时间戳。格式:<秒>.<微秒>，跟踪到函数handle_irq_pipelined_prepare()及父函数arch_pipeline_entry()，时间戳是进入handle_irq_pipelined_prepare()时的时间。
4.2 Latency trace输出格式
root@work-host:/sys/kernel/debug/tracing# cat trace
# tracer: irqsoff
#
# irqsoff latency trace v1.1.5 on 4.4.182
# --------------------------------------------------------------------
# latency: 2674 us, #28/28, CPU#6 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:8)
# -----------------
# | task: compiz-3483 (uid:1000 nice:0 policy:0 rt_prio:0)
# -----------------
# => started at: __wake_up
# => ended at: __wake_up
#
#
# _------=> CPU#
# / _-----=> irqs-off
# | / _----=> need-resched
# || / _---=> hardirq/softirq
# ||| / _--=> preempt-depth
# |||| / delay
# cmd pid ||||| time | caller
# \ / ||||| \ | /
compiz-3483 6d.s1 0us : _raw_spin_lock_irqsave <-__wake_up
compiz-3483 6d.s1 0us : preempt_count_add <-_raw_spin_lock_irqsave
......
compiz-3483 6d.s3 8us#: __x2apic_send_IPI_mask <-x2apic_send_IPI_mask
compiz-3483 6d.s3 2669us : ttwu_stat <-try_to_wake_up
compiz-3483 6d.s3 2671us : __rcu_read_lock <-ttwu_stat
compiz-3483 6d.s3 2671us : __rcu_read_unlock <-ttwu_stat
compiz-3483 6d.s3 2672us : _raw_spin_unlock_irqrestore <-try_to_wake_up
compiz-3483 6d.s3 2673us : preempt_count_sub <-_raw_spin_unlock_irqrestore
compiz-3483 6d.s2 2674us : _raw_spin_unlock_irqrestore <-__wake_up
compiz-3483 6d.s2 2674us : _raw_spin_unlock_irqrestore <-__wake_up
compiz-3483 6d.s2 2675us+: trace_hardirqs_on <-__wake_up
compiz-3483 6d.s2 2727us : <stack trace>
=> rcu_gp_kthread_wake
=> note_gp_changes
=> rcu_process_callbacks
=> __do_softirq
=> irq_exit
=> smp_apic_timer_interrupt
=> apic_timer_interrupt
=> __wake_up_sync_key
=> sock_def_readable
=> unix_stream_sendmsg
=> sock_sendmsg
=> sock_write_iter
=> do_iter_readv_writev
=> do_readv_writev
=> vfs_writev
=> SyS_writev
=> entry_SYSCALL_64_fastpat
第2行tracer的配置为irqsoff，tracer版本以及内核版本
下面一行给出最大延迟latency：2674us, 跟踪条目和总数
28
/
28
28/28
28/28，VP，KP，SP和HP始终为零，保留供以后使用。#P是在线CPU的数量（#P：8）。
延迟发生时运行的任务：compiz，任务PID：3483
分别禁用和启用中断导致延迟的：开始位置：__wake_up； 结束位置：__wake_up
内容及含义：
cmd：跟踪中进程的名称
pid:该进程的PID
CPU#:这个进程运行在这个CPU上
irq-off:
**‘d’**中断禁用，'.‘其它。注意：如果架构不支持某种方式读取irq标志变量，在这里会打印’X’
need-resched:
‘N’ TIF_NEED_RESCHED 和 PREEMPT_NEED_RESCHED两者都置位
‘n’ 只有TIF_NEED_RESCHED设置
‘p’ 只有PREEMPT_NEED_RESCHED设置
‘.’ 其它
hardirq/softirq:
‘Z’ --NMI发生在硬件中断内部
‘z’ --NMI运行
**‘H’ **–在一个softirq内发生了硬件中断。
**‘h’ **–硬中断运行
**‘s’ **–软中断运行
‘.’- -正常上下文
preempt-depth:
preempt_disable的级别
以上内容对内核开发人员来说最有意义。
time:
启用 latency-format 选项时，跟踪文件输出包括相对于跟踪开始的时间戳。 这与禁用延迟格式时的输出不同，后者包括绝对时间戳。
delay:
不同时间戳前后的差异，主要为了容易找到前后时间差大的。
‘$’ - 超过1秒
‘@’ - 大于100ms
‘*’ - 大于10ms
‘#’ - 大于1000us
‘!’ - 大于100us
‘+’ - 大于10us
’ ’ - 小于等于10us
其余部分与’trace’文件相同（4.1 trace输出格式）。
请注意，延迟跟踪器通常以反向跟踪结束，以便轻松找到延迟发生的位置。
4.3 trace_options
trace_options文件（或options目录）用于控制在跟踪输出中打印的内容，要查看哪些有效，cat这个文件：
root@work-host:/sys/kernel/debug/tracing# cat trace_options
print-parent
nosym-offset
nosym-addr
noverbose
noraw
nohex
nobin
noblock
trace_printk
annotate
nouserstacktrace
nosym-userobj
noprintk-msg-only
context-info
nolatency-format
record-cmd
norecord-tgid
overwrite
nodisable_on_free
irq-info
markers
noevent-fork
nopause-on-trace
hash-ptr
function-trace
nofunction-fork
nodisplay-graph
nostacktrace
notest_nop_accept
notest_nop_refuse
要禁用某一个options，将这这一项前添加no,然后echo到trace_options：
echo noprint-parent > trace_options
启用options：
echo sym-offset > trace_options
以下是可用options及含义：
-
print-parent: 在函数跟踪上，显示调用（父）函数以及正在跟踪的函数，如。
#echo print-parent > trace_options
bash-4000 [01] 1477.606694: simple_strtoul <-kstrtoul
#echo noprint-parent > trace_options
bash-4000 [01] 1477.606694: simple_strtoul
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
