哪个工具可以找到嵌入式 Linux 上出现延迟峰值的原因？
Which tool for finding the reason for latency peaks on embedded Linux?
最好的情况是，如果我有一个在后台运行的（调试）工具，它会告诉我打破我对系统的延迟要求的进程或驱动程序的名称。哪种工具合适？您是否有以下情况的简短示例？
测试用例：
- 示波器测量 GPIO 输入触发与 GPIO 输出响应之间的时间。通常响应时间为 150µs。我每 25 毫秒触发一次。
- 我的 linux 用户测试程序使用 poll() 和 read()+write() 将检测到的输入信号镜像为对输出的响应。
- Linux 内核打了 Preempt_rt 补丁。
- 在小时的维度上，我可以看到响应时间峰值高达 20 毫秒。
最好的机会是
- 在内核配置中打开跟踪并构建这样的 Linux 内核：
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_STACK_TRACER=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_DEBUG_FS=y
- 然后 运行 您的应用程序，直到使用工具
trace-cmd 发生奇怪的事情
trace-cmd start -b 10000 -e 'sched_wakeup*' -e sched_switch -e gpio_value -e irq_handler_entry -e irq_handler_exit /tmp/myUserApplication
并获得一个 trace.dat 文件。
trace-cmd stop
trace-cmd extract
- 在 KernelShark 中加载 trace.dat 文件并分析 CPU、线程、中断、kworker 线程和用户 space 线程。很高兴看到哪些阻止了系统。
最好的情况是，如果我有一个在后台运行的（调试）工具，它会告诉我打破我对系统的延迟要求的进程或驱动程序的名称。哪种工具合适？您是否有以下情况的简短示例？
测试用例：
- 示波器测量 GPIO 输入触发与 GPIO 输出响应之间的时间。通常响应时间为 150µs。我每 25 毫秒触发一次。
- 我的 linux 用户测试程序使用 poll() 和 read()+write() 将检测到的输入信号镜像为对输出的响应。
- Linux 内核打了 Preempt_rt 补丁。
- 在小时的维度上，我可以看到响应时间峰值高达 20 毫秒。
最好的机会是
- 在内核配置中打开跟踪并构建这样的 Linux 内核：
CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y CONFIG_SCHED_TRACER=y CONFIG_FTRACE_SYSCALLS=y CONFIG_STACK_TRACER=y CONFIG_DYNAMIC_FTRACE=y CONFIG_FUNCTION_PROFILER=y CONFIG_DEBUG_FS=y
- 然后 运行 您的应用程序，直到使用工具
trace-cmd 发生奇怪的事情
trace-cmd start -b 10000 -e 'sched_wakeup*' -e sched_switch -e gpio_value -e irq_handler_entry -e irq_handler_exit /tmp/myUserApplication
并获得一个 trace.dat 文件。
trace-cmd stop trace-cmd extract
- 在 KernelShark 中加载 trace.dat 文件并分析 CPU、线程、中断、kworker 线程和用户 space 线程。很高兴看到哪些阻止了系统。