我有一个光纤链路，带有专有的设备驱动程序
该链接进入PCIe卡。在RHEL 5.2上运行（2.6.18-128~）
我已经mmap对卡上的接口进行了设置和FIFO访问等，这些读/写需要几μs才能完成，所以一切都很好。
但当然不能将它用于中断，所以我必须使用提供的内核模块，以及它的用户空间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，并将其与固件中的当前时间进行比较）
发生中断与User Space API中断调用等待方法返回之间的预期访问时间是什么？
网络/其他高速接口需要？
答案 0 :(得分：3)
500ms 许多的数量级大于用户空间/内核之间的简单切换，但正如评论中提到的那样，linux不是实时操作系统，所以不能保证500ms“hickups “不会偶尔出现。
很难说出罪魁祸首是什么，设备驱动程序可能会简单地尝试捆绑数据以提高效率。
也就是说，我们遇到了一些自定义卡以及与APIC和ACPI交互的无穷无尽的麻烦，需要精确平衡BIOS设置，哪个卡进入哪个PCI插槽以及特定视频卡是否搞砸了所有内容 - 可能一个可疑的司机与或多或少的马车/视频卡交互的原因..
答案 1 :(得分：2)
如果您有最新的内核，可以使用perf sched工具来衡量延迟，并查看使用时间的位置。 （500us听起来有点偏高，取决于你的处理器，正在运行的任务数量，......）
答案 2 :(得分：2)
如果你能够在没有负载很重的系统上可靠地超过500us，我认为你正在寻找一个糟糕的驱动程序实现（或其用户空间包装器/对应物）。
根据我的经验，在中断时唤醒用户线程的延迟应小于10us，但（正如其他人所说）Linux没有提供延迟保证。