代码之家 › 专栏 › 技术社区 › Ian Vaughan

低延迟中断处理(预期从内核返回用户空间的平均时间是?)

interrupt linux-device-driver real-time linux-kernel linux

Ian Vaughan · 技术社区 · 14 年前

我有一个光纤链路,带有一个专用的设备驱动程序。
链接进入PCIe卡。在RHEL 5.2(2.6.18-128~)上运行
我有 mmap 'ed卡上用于设置和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微秒。(引发中断的时间锁定在固件中,我读到这一点,正如我前面所说,需要大约2微秒,并将其与固件中的当前时间进行比较)

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

网络/其他高速接口需要?

3 回复 | 直到 14 年前

Eric Seppanen 14 年前

如果在一个负载不重的系统上,您能够可靠地超过500us,那么我认为您看到的是一个糟糕的驱动程序实现(或者它的用户空间包装器/对应物)。

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

nos 14 年前

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

很难分辨出罪魁祸首是什么,设备驱动程序可能会简单地试图将数据捆绑在一起以提高效率。

也就是说,我们在一些定制卡和与APIC和ACPI的交互方面遇到了无尽的麻烦,需要在BIOS设置、哪个卡进入PCI插槽以及某个特定的视频卡是否破坏了一切之间保持微妙的平衡,这可能是一个可疑的驱动程序与Mo交互的原因。或者更少有缺陷的BIOS/视频卡。

caf 14 年前

如果您有最近的内核,可以使用 perf sched 用于测量延迟的工具,并查看时间的使用位置。(500us确实听起来有点偏高,这取决于您的处理器,有多少任务正在运行…)

推荐文章

Furkan Gözükara · 如何修改此命令以安装特定的cuDNN和torch版本“apt-install-libcudnn8”

1 年前

CaTx · 使用带有一个大于号和两个大于号的回波的区别

2 年前

Ari157 · x86_64 Linux程序集中的逻辑与实现

2 年前

user2954003 · AWK使用正则表达式匹配字符串并与前一个字符串组合

2 年前

twisted · 将apache2 CustomLog管道传输到以其他用户身份运行的程序

2 年前

domagaja · Linux—更快地读取或收集文件内容(例如,每秒的cpu温度)

2 年前

Ty Q. · 分段故障GLFW3/GLAD

2 年前

Code With Banchi · 在sed命令中使用变量-sed-e异常:“s”的选项未知

2 年前

ShortArrow · 如何使用git管理链接源文件?

2 年前

Bastien L. · 多Linux Grafana集成

2 年前