am335x linux内核烧写_实时 Linux 抖动分析 Step by step

本文首次发表于 实时 Linux 抖动分析 Step by step

前段时间有同学问到：

大家有显卡方面实时性调优经验交流吗？我现在是 x86，不加显示任务实时性可以保持在 20us 内，如果加上显示，抖动就飙升到 70us，其实显示是辅助功能。

其实造成抖动的原因已经清楚了，但是要解决问题还得定位到具体的代码，到底是哪段代码造成了这么大的抖动呢？

从问题本身来看，这个应该是可复现的，所以接下来就是要解决它。

解决这类问题通常是用专属工具 Ftrace 的 Max Latency Tracing，大体用法可参考 Documentation/trace/ftrace.rst。

大体分析过程如下：

使用抢占内核或者 preempt-rt 内核

如果用普通内核，请在内核 General setup 下 preemption model 开启 low-latency desktop。

CONFIG_PREEMPT=y

从问题来看，应该是已经用上了实时抢占内核，这时需要打开如下配置：

CONFIG_PREEMPT_RT_FULL=y

如果没有使用，得参考 实时 Linux 一文从 发布地址 找到相应版本的 patch 打上，并针对所用板子做进一步优化，而且要关闭很多可能影响实时性能的调试选项。

配置内核，打开中断和抢占关闭等 tracer

在内核配置 Kernel Hacking 下 Tracers

--- Tracers [*] Kernel Function Tracer [*] Kernel Function Graph Tracer [*] Interrupts-off Latency Tracer [*] Preemption-off Latency Tracer [*] Scheduling Latency Tracer [*] Enable upbrobed-based dynamic events [*] enable/disable function tracing dynamically

重新编译内核，启动到问题现场并开始分析

先确保能复现问题的场景是一直在跑的，然后就是参考上面 ftrace.rst 用法开始 tracing。

稍微补充几点小技巧：

• sys/kernel/tracing 挂载
  默认这个目录可能没挂载，

$ mount -t tracefs none /sys/kernel/tracing

早期内核可能用的 /sys/kernel/debugfs/tracing 目录，需要先挂载 debugfs 如下：

$ mount -t debugfs none /sys/kernel/debugfs

• tracers：irqsoff, preemptoff, preemptirqsoff
  建议先用第三个，再逐步用第一个和第二个。第三个是两个的或，如果先用第一个或者第二个，即使解决了发现的问题，也可能不是造成 max latency 的热点路径。
• 开始 tracing 前，清空历史记录
  启动新的 tracing 之前，记得清空上次记录，避免造成误判，以 irqsoff 为例：

$ echo 0 > options/function-trace$ echo irqsoff > current_tracer$ echo 1 > tracing_on$ echo 0 > tracing_max_latency$ do something for repeat the issue scene$ echo 0 > tracing_on$ cat trace > trace.log

最后就是分析日志和解决问题，原因不外乎是长时间关了抢占或者关了中断，这个就得具体问题具体分析，看情况是要做中断线程化还是主动加调度点等等。

对于 tracing 日志分析，类似 Android 上的 Systrace 图形化分析工具，Linux 上有 kernelshark。

---

本专栏作者首开视频课，欢迎报名或引荐~

总结

以上是生活随笔为你收集整理的am335x linux内核烧写_实时 Linux 抖动分析 Step by step的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。