multithreading - 澄清 request_threaded_irq 的行为

Question

我已经在网上搜索过，但对于我遇到的几个与“request_threaded_irq”功能相关的问题，还没有找到令人信服的答案。

问题1:
首先，我正在阅读这篇关于线程 IRQ 的文章:

http://lwn.net/Articles/302043/

我不清楚这一行:

“将中断转换为线程只有在处理程序时才有意义
代码通过集成 tasklet/softirq 来利用它
功能并简化锁定。”

我知道如果我们继续采用“传统”的上半部分/下半部分方法，我们将需要自旋锁或禁用本地 IRQ 来干预共享数据。但是，我不明白的是，线程中断如何通过集成 tasklet/softirq 功能来简化锁定需求。

问题2:
其次，request_threaded_handler 方法比基于 work_queue 的下半部分方法有什么优势(如果有的话)？在这两种情况下，似乎“工作”都被推迟到了一个专用线程。那么区别是什么呢 ？

问题3:
最后，在以下原型(prototype)中:

int request_threaded_irq(unsigned int irq, irq_handler_t handler, irq_handler_t thread_fn, unsigned long irqflags, const char *devname, void *dev_id)

是否有可能 IRQ 的“处理程序”部分由相关 IRQ 连续触发(比如 UART 以高速率接收字符)，即使“thread_fn”(将 rx'd 字节写入循环缓冲区)部分中断处理程序正忙于处理来自先前唤醒的 IRQ 吗？那么，处理程序不会试图“唤醒”已经运行的“thread_fn”吗？在这种情况下，正在运行的 irq thread_fn 会如何表现？

如果有人能帮助我理解这一点，我将不胜感激。

谢谢，
vj

Answer 1

对于问题 2，
与工作队列不同，创建时设置的 IRQ 线程具有更高的优先级。
在 kernel/irq/manage.c ，您将看到如下代码，用于为线程 IRQ 创建内核线程:

            static const struct sched_param param = {
                    .sched_priority = MAX_USER_RT_PRIO/2,
            };


            t = kthread_create(irq_thread, new, "irq/%d-%s", irq,
                               new->name);
            if (IS_ERR(t)) {
                    ret = PTR_ERR(t);
                    goto out_mput;
            }

            sched_setscheduler_nocheck(t, SCHED_FIFO, &param);

在这里可以看到，内核线程的调度策略设置为 RT 之一( SCHED_FIFO )，线程的优先级设置为 MAX_USER_RT_PRIO/2这高于常规流程。

对于问题 3，
您描述的情况也可能发生在正常中断中。通常在内核中，中断在 ISR 执行时被禁用。在 ISR 执行期间，字符可以不断填充设备的缓冲区，并且即使在中断被禁用时，设备也可以并且必须继续断言中断。

设备的工作是确保 IRQ 线保持有效，直到读取所有字符并且 ISR 完成任何处理。同样重要的是中断是电平触发的，或者取决于设计被中断 Controller 锁存。

最后，设备/外设应具有足够大小的 FIFO，以便高速传输的字符不会被慢 ISR 丢失。 ISR 还应设计为在执行时读取尽可能多的字符。

一般来说，我所看到的是， Controller 将具有一定大小的 FIFO X ，当 FIFO 被填满时 X/2 ，它会触发一个中断，导致 ISR 获取尽可能多的数据。 ISR 尽可能多地读取，然后清除中断。同时，如果 FIFO 仍然是 X/2 ，设备将保持中断线有效，导致 ISR 再次执行。