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

我有一个光纤链路，带有专用设备驱动程序。
该链路进入PCIe卡。在RHEL 5.2（2.6.18-128~）上运行
我已经

mmap

”为卡上的接口设置了设置和FIFO访问等功能，这些读/写操作需要几微秒才能完成，因此在那里一切都很好

但当然不能将其用于中断，因此我必须使用提供的内核模块及其用户空间库接口

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中断调用等待方法返回之间的预期访问时间是多少

网络/其他高速接口需要多少时间？

500ms比用户空间/内核之间的简单切换需要多少数量级，但正如有人在评论中提到的，linux不是实时操作系统，所以不能保证500ms的“hickups”不会不时出现

很难说罪魁祸首是什么，设备驱动程序可能只是为了更高效地捆绑数据

---

也就是说，我们在一些定制卡以及与APIC和ACPI的交互方面遇到了无尽的麻烦，需要bios设置的微妙平衡，哪个卡进入哪个PCI插槽，以及某个特定的视频卡是否会把所有事情都搞糟——可能是驱动程序与或多或少有缺陷的bios/视频卡交互的原因。

如果您有一个最新的内核，您可以使用该工具测量延迟，并查看使用时间的位置。（500us听上去有点偏高，这取决于你的处理器，有多少任务正在运行，…）

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

---

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

Linux不是实时操作系统。我认为我不需要实时，只需要快速时间！为了测量从内核到用户空间的中断延迟，我们必须模拟中断吗？我想看看如何测量这个。