我正在使用视频编码基准测试应用程序。对我来说奇怪的是，当我使用该命令时，sudo chrt -r 99 VideoEncoding cfg我总是会得到更长的时间（更糟糕的结果），而不是仅仅使用VideoEncoding cfg.对于 150 帧，它们之间的差异约为 200 秒，这是巨大的。人们认为改变进程的实时属性会更快，但事实证明它会更慢。
有人可以解释一下吗？
PS：我在 Ubuntu 20.04 LTS 下运行基准测试
答案1
假设改变进程的实时属性会更快
这绝对是错误的。
在实时策略下安排任何事情可能有助于实现精确且确定的延迟、任务之间的同步……但是因为没有免费的午餐以牺牲吞吐量为代价。
在任何 CPU 密集型任务（视频编码任务是什么）的特定情况下，您想要的是：吞吐量！
因此……调度此类任务 SCHED_RR 只会降低系统上所有内容的性能（包括……您的基准测试应用程序）。
而且您的 cpu 密集型任务越是多线程（可能是现代 cpu 密集型任务），您观察到的性能下降就越多。
重新优化应该足以实现更好的性能，或者在极限情况下，如果需要尽可能高的性能，那么就把这个任务安排在一些空闲的 CPU 上。
并且，顺便说一句：永远不要、永远不要以最大可能的优先级安排任何 RT。如果出现任何问题，除了硬件重置之外，您将无法执行任何其他操作。
更不用说 BTW 2：用在同一系统下运行的任何基准测试应用程序对任何 RT 系统进行基准测试是荒谬的。
答案2
假设改变进程的实时属性会更快，
不，那不是真的！
让进程“实时调度”并不会使其变得更快，它只是保证调度进程之间的最大时间。这可能会导致更多的上下文切换，从而有效地使系统变慢。