[参考译文] TDA4VH-Q1：对 Linux/A72和 MCU 岛 R5F 之间的(软)实时系统使用 rpmsg

尊敬的 Robert：

Unknown 说：

-该核心运行的 kworker

-我们的 A72应用程序被唤醒并接收数据

[/报价]

邮箱中断处理程序安排工作队列功能(kworker 线程)的邮箱处理，这是处理传入 rpmsg 消息的一个线程。

kWorker 线程应在邮箱通道创建期间创建、并且应保持不变。 这不会重新生成(不确定您的定义是什么)。

Unknown 说：

您是否知道可以跳过 kworker 的使用并在中断处理程序期间直接完成所有操作的任何 Linux 配置选项？ [/报价]

不、我们不支持这一点。 这以前是 tasklet、但它们完全被阻止、邮箱驱动程序已经从使用 tasklet 远远移到了 workqueue。

我对你关于固定 kworker 线程的低优先级线程的说法感到困惑。 您如何确定它确实是被挂起的 kworker 线程而不是应用程序读取线程？

此致

苏曼

[/quote]

感谢您花时间回答。 我会尽量解决您的问题。

Eason Zhang 说：

创建 kworker 线程应在邮箱通道创建期间创建，并且应保持不变。 这不会重新生成(不确定您的定义是什么)。

显然、我们的系统中创建了新的 kworker 线程。 当我们在几个小时后查看系统时，正在运行(用 ps 检查)的 kworker 线程具有较高的 pid (与系统开始时相比)，并再次具有其默认优先级。 IRQ 线程和我们的 A72程序保持不变(相同的 PID)。

Eason Zhang 说：

您关于固定 kworker 线程的低优先级线程的说法令我感到困惑。 您如何确定它确实是被挂起的 kworker 线程而不是应用程序读取线程？

查看使用内核鲨鱼的 ftrace。 对于延迟的周期、我们可以看到低优先级任务恰好在同一个内核上运行。 该低优先级任务会被中断或其他实时任务等实时任务中断、但不会被同样具有实时优先级的 A72应用中断。 因此、我们假设 A72应用程序(在 rpmsg 器件上等待读取)在可能的情况下也会中断该低主域任务、但它必须等待 kworker 运行、 不幸的是、这最初是以低优先级开始的、并且必须等待另一个低优先级任务完成(或默认的 Linux 调度程序需要获取一个时间片)。

这是此类情况的轨迹。 蓝色是正在运行的低 prio 任务(在本例中为 pidstat)。 左侧的第一个框包含正确中断蓝色线程的 IRQ 线程。 第二个框是另一个正确中断蓝色线程的实时 PRIO 线程的示例。 第三个也是最后一个框是 kworker 最终接收其时间片、然后它还提示我们的实时 A72程序运行并完成通信。

尊敬的 Robert：

Unknown 说：

显然我们的系统中创建了新的 kworker 线程。 当我们在几个小时后查看系统时，正在运行(用 ps 检查)的 kworker 线程具有较高的 pid (与系统的开头相比)并再次具有其默认优先级。

在引导期间，当探测 Linux Remoteproc 和 rpmsg 内核模块时，将创建 Mailbox kworker 线程。 应该能够确定与邮箱关联的 kworker 线程。

Unknown 说：

它必须等待 kworker 运行，但不幸的是，它开始时优先级较低，并且必须等待另一个 low-prio 任务完成(或默认 Linux 调度程序获得时间片)。

低优先级任务和 kworker 线程的线程优先级是多少？ 我感到惊讶的是、用户空间发散的线程具有比内核发散的 kworker 线程更高的优先级。

您在 RT-Linux 上运行它吗？ 您在常规 Linux 上看到的行为是否相同(您的应用程序往返使用量也应完全处于常规 Linux 上的延迟范围内)。

您是否无法使用 很好 调整 kworker 线程优先级的命令？

此致

苏曼

Eason Zhang 说：

当探测 Linux remoteproc 和 rpmsg 内核模块时，在引导期间将已创建邮箱 kworker 线程。 您应该能够确定与邮箱关联的 kworker 线程。

我理解您的说法、我们也希望它能够以这种方式发挥作用。 在测试开始时、我们已经更改了特定内核的所有 kworker 线程的优先级。 之后、系统运行几个小时。 但经过一段时间后、即使系统不间断运行、原始 kworker 线程也会消失。 新的 kworker 线程再次具有其原始优先级、这不可避免地会导致低优先级线程的干扰(如上所述)。

Eason Zhang 说：

低优先级任务和 kworker 线程的线程优先级是什么？ 我感到惊讶的是,用户空间发散的线程具有比内核发散的 kworker 线程更高的优先级。

它们似乎具有相同的优先级(sched_other 和昵称为零)。 昵称0是 kworker 线程的默认优先级。 由于它们具有相同的优先级、默认调度程序会以相同的方式处理它们、因此用户空间线程可能会在超过其时间片之前运行一段时间。 只有在时间片用完后、kworker 才能开始。

我们以 Linux 内核6.1版作为记录。 我们还没有使用"正常"Linux 进行测试、但没有 preemple_rt 补丁。 您是否认为重新启动的 kworker 线程可能特定于 preempt_rt？

由于您非常确定通常不应重新启动 kworker 线程，因此我们将检查我们是否有某些 Linux 内核配置，这可能导致该行为。

尊敬的 Robert：

Unknown 说：

但是过了一段时间，原始 kworker 线程就会消失，即使系统运行不中断。

有趣,我没有亲自遇到这个,并且是非常奇怪的。 系统是以某种方式进行重新引导，还是 remoteproc 模块正在重新加载？ 这适用于所有 kworker 线程还是其中的几个线程？ 您通常看到这个有多长时间了？ 您能否提供有关这些的快照日志？

Unknown 说：

我们尚未在没有 preempt_RT 修补程序的"普通"Linux 中对其进行测试。 您是否认为重新启动的 kworker 线程可能特定于 preempt_rt？

我不知道。

此致

苏曼

PS：我下周早些时候外出度假、在下周晚些时候之前无法提供任何回复。

Eason Zhang 说：

有趣,我个人没有遇到这种情况,也很奇怪。 系统是以某种方式进行重新引导，还是 remoteproc 模块正在重新加载？ 这适用于所有 kworker 线程还是其中的几个线程？ 您通常看到这个有多长时间了？ 是否可以提供有关这些的快照日志？

此时系统不会重新启动、我们的所有相关任务(A72任务和 R5F 固件)都将继续运行。 没有指示内核模块已重新加载。

定期重新启动的 kworker 线程(似乎在几个小时后)只是通用 kworker 线程。 这似乎是预期的,因为这些一般目的的工人被保留或杀害在工作队的酌情。 请访问 https://www.kernel.org/doc/html/v6.1/core-api/workqueue.html ("保留闲置的工作人员不会花费 kthread 的内存空间以外的成本，因此 cmwq 会在闲置的工作空间中保留一段时间，然后再将其消灭。")

我一直在研究内核源，mbox 驱动程序和 rpmsg 驱动程序都没有创建专用的 kworker 线程。 mbox 驱动程序在中断函数(https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/mailbox/omap-mailbox.c?h=v6.1.78#n310)中使用"schedule_work"、该函数为这样的一般 kworker 线程排队。 rpmsg_char 实现似乎根本不使用 kworks，只是在读取期间等待队列中的数据。 (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/rpmsg/rpmsg_char.c?h=v6.1.78#n191)。 因此我们仍然认为我们的问题是(通用) kworker、它是由 mbox 中断触发的。

我们已经对这个小贴片进行了实验。

因此,我们明确要求一个高优先级的工人,运行在 sched_other 和 niceity -20。 这似乎运行得更好。 我们仍然需要运行一些更长时间的测试，但我们尝试了 stress-ng。 即使在100%的(非 RT)压力任务上运行 CPU 内核、我们也没有遇到问题。

如果将 mbox 驱动程序作为通信链的一部分、我认为应该使用这些更高优先级的队列。 你是否认为可以在上游做出这样的改变？

尊敬的 Robert：

Unknown 说：

我一直在研究内核源，mbox 驱动程序和 rpmsg 驱动程序似乎都没有创建专用的 kworker 线程。

是的。 OMAP 邮箱驱动程序只初始化一个工作项目并使用 Linux 系统的工作队列执行。 rpmsg 驱动程序回调是在同一上下文中执行的，用于处理传入消息，因此没有单独的 kworker 线程。

Unknown 说：

rpmsg_char 实现似乎根本不使用 kworker，只在读取期间等待队列中的数据即可。

rpmsg_char 驱动程序读数在用户应用程序读卡器线程的上下文中执行(取消消息队列)。 队列本身作为 rpmsg 驱动程序回调的一部分完成。

Unknown 说：

如果 mbox 驱动程序将成为通信链的一部分，我认为它应该使用这些较高优先级的队列。 您是否认为可以在上游进行这样的更改？

我认为这一点不能被上游接受,因为这种改变没有合理的理由。  每个 驱动程序使用者都可以进行相同的论据、而且都是相同的争用。

如果解决方案适合您、您可以在您的系统上进行更改。 我能想到的唯一一个解决方案是在整合之前使用专用工作队列(可能是内核所在的位置)，这也是一个树外解决方案。

此致

苏曼