打RT补丁出现偶发性抖动有什么方法排查？

[AlvinSkx]

1、使用了亲和性

[ilovenaibao]

你好，能问一下你们RT补丁是怎么打的吗？
ilovenaibao@163.com

[stoneForRock]

你好，能问一下你们RT补丁是怎么打的吗？
ilovenaibao@163.com

我也想知道，clone了rt分支的kernel代码 但是不知道怎么配置，make menuconfig也没有配置全实时系统的地方，应该是没有打补丁，但是不知道怎么打补丁的

[AlvinSkx]

你好：              可以参考这个x86 的链接中的前5步              https://blog.csdn.net/lsky380/article/details/90769058

…

------------------ 原始邮件 ------------------ 发件人: "rockchip-linux/kernel" ***@***.***>; 发送时间: 2023年6月16日(星期五) 下午4:20 ***@***.***>; ***@***.******@***.***>; 主题: Re: [rockchip-linux/kernel] 打RT补丁出现偶发性抖动有什么方法排查？ (Issue #260) 你好，能问一下你们RT补丁是怎么打的吗？ ***@***.*** 我也想知道，clone了rt分支的kernel代码 但是不知道怎么配置，make menuconfig也没有配置全实时系统的地方，应该是没有打补丁，但是不知道怎么打补丁的 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[chris-fengtian-guo]

你好：              可以参考这个x86 的链接中的前5步              https://blog.csdn.net/lsky380/article/details/90769058
…
------------------ 原始邮件 ------------------ 发件人: "rockchip-linux/kernel" @.>; 发送时间: 2023年6月16日(星期五) 下午4:20 @.>; @.@.>; 主题: Re: [rockchip-linux/kernel] 打RT补丁出现偶发性抖动有什么方法排查？ (Issue #260) 你好，能问一下你们RT补丁是怎么打的吗？ @.*** 我也想知道，clone了rt分支的kernel代码 但是不知道怎么配置，make menuconfig也没有配置全实时系统的地方，应该是没有打补丁，但是不知道怎么打补丁的 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

我的邮箱 fengtian_guo@hotmail.com 谢谢。
您好。 我也在瑞星微芯片上 移植 preempt rt 的补丁。 遇到很多kernel panic

1. 请问您， 具体是在那个 git 分支和 git commit 的代码。可以成功启动内核 full preempt RT ?
   希望您的成功案例。

B 介绍一下，我的实践和硬件情况。
1 硬件是rk3588 arm64 。 我用了 5.10-rt-53 分支。 打开 full preempt RT . 有几个编译错误 很容易解决。 但是内核启动panic 有很多地方。
2 昨天又试验了 4.19-rt104 分支代码， kernel panic 发生更早，有空指针。
3 我的配置，主要是把arch/arm64/configs 里面复制默认配置 和 dts, dtsi 等源文件复制 解决编译dtb 依赖的定义。

[chris-fengtian-guo]

同问: 你用cyclitest测试的抖动是多少? 我想用了ftrace去跟踪影响抖动的原因, 可是在启用PREEMPT_RT_FULL, 然后开启ftrace 直接死机,没有任何输出.

我使用的内核是4.19. 已经设置了cpu和irq隔离,cpu亲和, 测试结果是抖动大概是200us左右. 负载如下: 测试命令: cyclictest -l100000000 -m -Sp90 -i200 -h400 压力负载: stressapptest -M 500 -C -W -s 30000000 GPU负载: glmark2-es2-wayland

我的邮箱 fengtian_guo@hotmail.com 谢谢。
您好。 我也在瑞星微芯片上 移植 preempt rt 的补丁。 遇到很多kernel panic

1. 请问您， 具体是在那个 git 分支和 git commit 的代码。可以成功启动内核 full preempt RT ?
   希望您的成功案例。

B 介绍一下，我的实践和硬件情况。
1 硬件是rk3588 arm64 。 我用了 5.10-rt-53 分支。 打开 full preempt RT . 有几个编译错误 很容易解决。 但是内核启动panic 有很多地方。
2 昨天又试验了 4.19-rt104 分支代码， kernel panic 发生更早，有空指针。
3 我的配置，主要是把arch/arm64/configs 里面复制默认配置 和 dts, dtsi 等源文件复制 解决编译dtb 依赖的定义。

[xsyr]

我想开启 cpufreq，把cpu模式调整为 performance，看看是否能缓解抖动。但 打开 cpufreq 启动内核就崩溃了。

#317

[chris-fengtian-guo]

这个内核崩溃问题， 我已经解决了。 我用的是rk3588

[chris-fengtian-guo]

1. bug1 , 通过分析coredump 涉及的代码，垂直补强知识。 最后怀疑到 cpufreq_acct_update_power
   因为最初解决这个问题 担心坑很多，也联系了rockchip 2个主板厂商 - 淘宝 - 其中一个要报价5w . 我还是自研解决。
   1 因为高精度时钟 频率太高，不能将其进行线程化 ， 否则将下半部延迟到内核线程里 ， 时间精度无法保证。
   https://zhuanlan.zhihu.com/p/604906019 （参考这个问题解决）
   分析与解决：

这个中断是系统核心timer服务，至关重要。其通过request_percpu_irq注册中断isr，并不是常规request_irq或request_thread_irq，无法线程化。

继续分析崩溃调用栈，在崩溃前最后的操作为cpufreq_cpu_get，通过分析其源码，基本找到__account_system_time函数中调用了cpufreq_acct_update_power，其中又调用了rt_spin_lock函数导致崩溃。

通过分析cpufreq_acct_update_power函数，发现通过宏定义：CONFIG_CPU_FREQ_TIMES可以屏蔽该函数，进而不调用rt_spin_lock。

经测试，在menuconfig中，屏蔽CONFIG_CPU_FREQ_TIMES后，系统能正常启动到login环节。

2） 然后这个panic 解决后，我就能进入系统 登陆。 也能进行cyclictest 。 又解决了另外2个calldump 增加rt 系统稳定性。
回头 有时间我再把问题和解决patch 大概讲一下。 主要我的patch 在公司内网 不允许连接外网。 cyclictest 在stress 加压显著表现比没有rt内核强， 基本延迟在15 微秒。极少数到100多微秒，当然也有更稀少1000微秒 。2小时加压测试。
而非rt内核， 超过100微秒的次数还是显著多。

1 实时内核(preempt rt ) vs 非实时内核(non rt) 性能测试完成。 加压stress-ng --cpu 16 -l 100 (16个cpu线程，每个cpu负载100%) --io 20(20个io线程)， －－vm 100 --vm-bytes 500M(100个内存线程， 每个分配500M 内存)， --sock 100（100个socket线程）， --hdd 50(50个磁盘读写线程)。 1.1）cycltest 启动8个实时进程。 最小延迟在2－12 微秒，ACt在6－32 微妙，平均延迟在9－22 微秒。 最大延迟在46－110 微妙。 1.2) 非实时内核。 cycletest 最小延迟4微妙，Act 在11－52微秒，平均延迟在 11－52微妙。最大延迟4362－11023 微秒（而且比例很多）2.1）及时没有压力情况下， 非实时内核最大延迟也很高（1844－7370），实时内核最大延迟（11－40微妙）。 3.1）全部种类压力stress-ng 测试，创建1000个线程，每个线程会做所有种类压力（cpu,内存，磁盘，时钟，网络。 大概有30多种），10多分钟之后，实时内核会崩溃。 calldump

[chris-fengtian-guo]

calldump 并不影响linux系统启动和运行。

1. 已经把第一个calldump 原因调查清楚了。 下面是解决方案。
   rockchip_dfi_get_event()
   它会关闭该CPU上的中断。
   local_irq_save(flags)
   busier_ch = rockchip_dif_get_bussier_ch(edev);
   local_irq_restore(flags);
2. 但是里面更新事件 , 来重新设置设备的频率，
   通过regmap_read() 它会调用regmap_lock_spinlock() 实际上rt把spinlock替换成了mutex 会切换进程－睡眠－这个就是报错的calldump 原因 ___might_sleep()
3. 可能的解决方案， 调用 __regmap_init() 里面，锁有类型是regmap_lock_mutex , 而出bug的是设置位regmap_lock_spinlock，其中bus && bus->fast_io
   我的分析是相互矛盾的，应该是保持regmap_lock_spinlock() 使用rawspin_lock 是死等的原始spinlock - 不能切换。
   raw_spin_lock_irq(task->pi_lock);
   raw_spin_lock_irqsave(&pi_lock, flags)
   4）那么针对rt patch 它将spinlock替换为mutex, 将中断线程化 就是一种解决方案。