0

最好的情况是，如果我有一个（调试）工具，它在后台运行并告诉我打破我对系统的延迟要求的进程或驱动程序的名称。哪种工具适合？你有一个简短的例子来说明它在以下情况下的用法吗？

测试用例：

  • 示波器测量 GPIO 输入触发和 GPIO 输出响应之间的时间。通常响应时间为 150µs。我每 25 毫秒触发一次。
  • 我的 linux 用户测试程序使用 poll() 和 read()+write() 将检测到的输入信号作为对输出的响应进行镜像。
  • Linux 内核使用 Preempt_rt 补丁进行了修补。
  • 在小时的维度上，我可以看到高达 20 毫秒的响应时间峰值。
4

1 回答 1

0

最好的真正机会是

  1. 在内核配置中打开跟踪并构建这样的 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
  1. 然后运行您的应用程序，直到使用工具发生奇怪的事情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
  1. 在 KernelShark 中加载该 trace.dat 文件并分析 CPU、线程、中断、kworker 线程和用户空间线程。很高兴看到哪些阻止了系统。
于 2019-03-26T10:10:48.940 回答