2

我有一个带有专有设备驱动程序的光纤链路。
链接进入 PCIe 卡。在 RHEL 5.2 (2.6.18-128~) 上运行，
我已经mmap在卡上设置了接口，用于设置和 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 中断调用等待方法返回之间的预期访问时间是多少？

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

4

3 回答 3

3

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

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

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

于 2010-09-18T20:08:01.130 回答
2

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

于 2010-09-19T10:41:13.097 回答
2

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

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

于 2010-09-20T14:49:47.380 回答