我正在开发一个嵌入式应用程序，该应用程序在其执行的某些时期需要实时性能。
我通过调用将应用程序的优先级提升了大约 150 毫秒
sched_setscheduler(0, SCHED_FIFO, &s) 其中 s.sched_priority = sched_get_priority_max(SCHED_FIFO)，返回 99。
我在那里通过调用降低应用程序的调度优先级
sched_setscheduler(0, SCHED_OTHER, &s) 其中 s.sched_priority = sched_get_priority_min(SCHED_OTHER)。
此调度程序优先级升级/降级每秒发生一次。
我的申请中出现了间歇性的实时截止日期缺失。我想分析调度程序以确定实时执行周期是否被抢占。
perf sched 记录 -r 99 -R ./test_app
[性能记录：唤醒 9 次以写入数据] [性能记录：捕获并写入 10.272 MB perf.data（~448808 个样本）]
我正在寻找的是与我的应用程序关联的 sched_switch 事件，它参考优先级值 99。我可以确定我的应用程序应该将其调度优先级升级 n 次，如果我发现超过 n 个此类事件，那将暗示执行的实时部分被抢占。
使用以下命令将大量调度程序数据发送到标准输出：
性能计划跟踪 | grep test_app | grep sched_switch
我希望找到提到优先级为 99 的调度程序切换事件：
性能计划跟踪 | grep test_app | grep sched_switch | grep 优先级=99
然而上面的命令什么也没返回。
我正在使用性能版本 0.0.2.PERF。我是否对 perf 的行为或使用做出了错误的假设？如果是这样，任何人都可以建议正确的用法或其他替代分析 linux 实时调度程序的方法。