低延迟中断处理（从内核返回到用户空间的预期平均时间是？）答案

【问题标题】：low latency Interrupt handling (expected avg time to return from kernel to user space is?)低延迟中断处理（从内核返回到用户空间的预期平均时间是？）
【发布时间】：2010-09-18 19:34:28
【问题描述】：

我有一个带有专有设备驱动程序的光纤链路。
链接进入 PCIe 卡。在 RHEL 5.2 (2.6.18-128~)上运行
我已经mmap'ed 卡上的接口，用于设置和 FIFO 访问等，这些读/写需要几微秒才能完成，所以一切都很好。

当然不能用它来中断，所以我必须使用提供的内核模块，以及它的用户空间 lib 接口。

WaitForInterrupt(); // API lib interface to kernel module
// Interrupt occurs and am returned to my code in user space
time = CurrentTime() - LatchedTime(); // time to get to here

从 WaitForInterrupt() 返回大约需要 70µs。（引发中断的时间被锁在固件中，我读到了这个，正如我上面所说的大约需要 2µs，并将其与固件中的当前时间进行比较）

从发生中断到用户空间 API 中断调用等待方法返回之间的预期访问时间是多少？

网络/其他高速接口占用？

【问题讨论】：

Linux 不是实时操作系统。
我认为我不需要实时，只需要快速！

标签： linux linux-kernel real-time linux-device-driver interrupt

【解决方案1】：

500ms 比用户空间/内核之间的简单切换要大许多个数量级，但是正如 cmets 中提到的那样，linux 不是实时操作系统，因此不能保证 500ms “hickups” " 不会时不时出现。

很难说出罪魁祸首是什么，设备驱动程序可能只是试图捆绑数据以提高效率。

也就是说，我们在一些自定义卡以及与 APIC 和 ACPI 的交互方面遇到了无穷无尽的麻烦，需要在 bios 设置、什么卡插入哪个 PCI 插槽以及特定的视频卡是否搞砸一切——可能可疑驱动程序与或多或少有问题的 bios/视频卡交互的原因..

【讨论】：

为了测量从内核到用户空间的中断延迟，我们必须模拟中断吗？我正在尝试了解如何衡量这一点。

【解决方案2】：

如果您能够在负载不重的系统上可靠地超过 500us，我认为您正在寻找一个糟糕的驱动程序实现（或其用户空间包装器/对应物）。

根据我的经验，在中断时唤醒用户线程的延迟应该小于 10us，尽管（正如其他人所说）Linux 不提供延迟保证。

【讨论】：

【解决方案3】：

如果您有最新的内核，您可以使用perf sched 工具来测量延迟，并查看时间在哪里使用。（500us 听起来确实有点偏高，具体取决于您的处理器、正在运行的任务数量……）

【讨论】：