提高 linux kworker 线程优先级？

Increase linux kworker thread priority?

提问人：Gyorgy Szekely 提问时间：11/13/2023 最后编辑：Gyorgy Szekely 更新时间：11/14/2023 访问量：57

问：

我有一个带有 linux 的双核 1GHz ARM 系统，其中业务应用程序应执行低延迟串行 IO> <10ms 响应时间，接收 ~10 字节请求，发送 ~20字节响应。经过几次迭代的设计改进后，结果相当不错，但偶尔仍会错过最后期限。

对 Perfetto.dev 进行系统范围的跟踪揭示了以下内容：

  • 当两个内核都饱和时，就会错过最后期限
  • 应用程序线程具有更高的优先级，一旦它变得可运行，它就会以 <100us 进入运行状态，并在 2ms 内执行其工作（完全在规范范围内）
  • 应用程序线程由 kworker/u4：1-events_unbound（处理串行硬件）唤醒，这与其他用户线程具有相同的 prio
  • 当错过最后期限时，是 kworker 挨饿了（保持可运行状态，等待可用的 CPU 资源）

由于 CPU 不时饱和，我认为除了优先考虑有截止日期的线程之外，没有其他选择。但是改变 kworker 线程（renice、chrt）的优先级至少可以这样说：

  • 它们归内核所有，更改它们的 prio 感觉不对
  • 它们是创建和销毁运行时的，扫描它们并在启动时设置 prio 一次是不可行的

解决这个问题的正确方法是什么？

将更多内核投入工作不是一种选择。即使 CPU 饱和，跟踪也表明，如果执行正确的事情而不是一些后台活动，则可以轻松满足最后期限。

--

enter image description here

此跟踪描述了问题的单次出现：

  • 该标志指示流量到达的时间点：6 字节
  • 此时，kworker 变得可运行，但在此状态下保持 6.7 毫秒
  • 在此期间，两个内核上都计划了多个进程
  • 当 kworker 最终运行时，它会唤醒我的线程并运行应用程序代码
多 实时 嵌入式 Linux 线程优先级

评论

0赞 Clifford 11/14/2023
你用的是RT-KERNEL吗？如果你有实时截止日期，你可能应该这样做。最高优先级的可运行线程运行。应优先考虑 RMA 原则。尽管只有嵌入式 Linux 用户才会将 10 毫秒视为低延迟。对于硬实时，你真的希望你的操作系统不碍事。
0赞 Jérôme Richard 11/14/2023
AFAIK，内核线程在设计上确实具有更高的优先级。这篇文章也往往证实了这一点。您确定这是任务调度问题而不是 IO 调度问题，和/或只是 IO 设备已经饱和吗？您是否检查过 IO 调度程序已准备好读回数据，并且内核线程在此之后没有直接运行？顺便问一下，目标 IO 设备是什么？HDD 的延迟很高，因此 10 毫秒太紧了，但 Nvme SSD 显然应该能够达到这个延迟。
0赞 Jérôme Richard 11/14/2023
就我个人而言，我会使用具有高优先级（手动设置）的 IO 线程，使用异步 IO API（如 io_uring）来满足非常高的性能和低延迟要求。由于我希望内核线程的优先级高于关联的用户线程，因此在这种情况下应该不会出现延迟问题，除非设备已饱和，因此并发请求的顺序开始变得至关重要（我看到这样的事情发生在 HDD 上，但还没有发生在 SSD 上）。线程通信会带来开销，但它们比目标最大延迟小 <1000 倍。
0赞 Jérôme Richard 11/14/2023
顺便问一下，您是否拥有比可用内核更多的现成用户线程？如果是这样，那么如果某些线程执行完全受计算限制的操作，则调度程序的量可能是一个问题。AFAIK，当时序小于量子时，即使使用 IO 绑定的线程，也无法保证公平性。我希望它有所帮助。
0赞 Gyorgy Szekely 11/14/2023
@Clifford 使用普通的 linux 内核，正如你所写的，我的截止日期比通常的实时系统少 2 个数量级。音频处理在消费类操作系统上具有类似的截止日期，几个字节的串行数据处理也应该有效。

答： 暂无答案

上一个：最佳实践？OSM 层，具有移动的 gps 数据，每 5 秒更新一次

下一个：通过 API 访问各种社交媒体平台的实时关注者计数