c++ - 内核模块和 SCHED_RR 线程的优先级

Question

我有一个嵌入式 Linux 平台(Beagleboard，运行 Angstrom Linux)，连接了两个设备:

• 通过 USB 连接的激光测距仪 (Hokuyo UTM 30)
• 通过 SPI 连接的自定义外部板

我们编写了一个负责SPI数据传输的Linux内核模块。它有一个 IRQ 处理程序，其中 spi_async被调用，这反过来会导致调用异步回调方法。

我的 C++ 应用程序包含三个线程:

• 数据处理的主线程
• 激光轮询线程
• 一个 SPI 轮询线程

我遇到的问题似乎是由上述模块的交互方式引起的。

• 当我关闭 USB 设备(激光测距仪)时，我会正确接收所有 SPI 消息(每 3 毫秒 1 条消息，消息长度除以数据速率为 <1 毫秒)，独立于线程调度
• 当我打开 USB 设备并使用正常的线程调度(SCHED_OTHER，优先级 0，没有很好的级别设置)运行我的程序时，大约 1% 的消息“丢失”，因为 spi_async 的回调方法在运行时下一个 IRQ 发生(为了不丢失消息，我可以不同地处理这种情况，所以这不是一个大问题。)

• 打开 USB 设备并使用 SCHED_RR 和运行程序

  • 主线程的优先级 = 10
  • SPI 读取线程的优先级 = 10
  • USB/激光轮询线程的优先级 = 4

  然后我丢失了 40% 的消息，因为在调用 spi-callback 方法之前再次触发了 IRQ! (我仍然可以找到解决方法，但问题是我需要快速响应时间，在这种情况下无法再达到)。我需要使用线程调度和激光设备，所以我正在寻找一种方法来解决这个问题。

问题一:

我的假设是内核空间中由 spi_async 触发的 IRQ 处理程序和回调的优先级高于用户空间中运行的任何线程(无论是 SCHED_RR 还是 SCHED_OTHER)。这意味着在我的应用程序中转向 SCHED_RR 不应该减慢 SPI 传输，但这似乎是非常错误的。是吗？

问题二:

我如何确定这里发生了什么？存在哪些调试辅助工具？ (或者也许您不需要任何进一步的信息？)我的主要问题是:为什么只有在激光设备打开时我才会遇到这些问题。 USB驱动会耗费这么多时间吗？

----- 编辑:

我做了以下观察:

spi_async 的回调调用 wake_up_interruptible(&mydata->readq);(使用 wait_queue_head_t readq;)。在用户空间(我的应用程序)中，我调用了一个函数，结果为 poll_wait(file, &mydata->readq, wait); 当轮询返回时，用户空间调用 read()。

• 当我的应用程序使用 SCHED_OTHER 运行时，我可以看到回调方法首先完成，然后我的内核模块中的 read() 方法被输入。
• 当我的应用程序以 SCHED_RR 运行时，在退出回调之前输入读取。

这似乎证明了用户空间线程的优先级高于回调方法上下文的优先级。有没有什么方法可以改变这种行为并且仍然为我的应用程序线程提供 SCHED_RR？

Answer 1

并非所有内核线程都具有 RT 优先级。想象一个需要做一些后台工作的周期性唤醒线程正在唤醒。您不希望此线程抢占您的 RT 线程。所以我猜你的第一个假设是错误的。

根据您的其他问题:

• 您的主处理循环通过队列接收 SPI 数据
• spi 处理线程向主处理队列提供数据

您的主处理线程似乎妨碍了负责 spi 数据传输的 spi 驱动程序线程。

这是发生了什么:

• IRQ 被触发
• spi_async 被调用，这意味着数据传输已排队，将由 spi 主驱动程序创建的线程获取。
• spi 主线程与您的主处理线程(激光线程)竞争，但该内核线程没有 RT 优先级，因此每次运行 RR 线程时它都会丢失。

你可以做的是回到正常的调度，同时使用各种 CONFIG_PREEMPT_ 选项。或者弄乱 spi 主驱动程序，以确保任何延迟的工作都以足够的优先级排队。甚至根本不排队。