linux - ioread 中的延迟

标签 linux real-time drivers pci-e

假设您有一个 PCIE 设备,它显示一个 BAR 和一个用 pci_alloc_consistent(..) 声明的 DMA 区域。 BAR 的标志指示不可预取、不可缓存的内存区域。

读DMA区延迟的主要原因是什么,同样,读BAR延迟的原因是什么?

感谢您回答这个简单的问题 :D!

最佳答案

这听起来有点像家庭作业,但我怀疑很多人对这些概念的理解并不充分,所以我会添加一个答案。

思考这个问题的最佳方法是考虑为了完成读取需要发生什么。 CPU 和设备位于 PCIe 链路的不同端。将 PCI-Express 视为迷你网络很有帮助。每个链接都是点对点的(就像您的 PC 连接到另一台 PC)。也可能有中间开关(也称为 PCI 中的桥接器)。在这种情况下,就好像您的 PC 连接到交换机,而交换机又连接到另一台 PC。

因此,如果 CPU 想要读取自己的内存(您分配的“DMA”区域),它的速度相对较快。它有一个高速总线,旨在快速实现这一目标。此外,还内置了多层缓存以将频繁(或最近)使用的数据“靠近”CPU。

但是如果CPU要从设备中的BAR中读取,CPU(实际上是与CPU集成的PCIe Root Complex)必须组成一个PCIe读取请求,发送请求,等待设备解码请求,访问 BAR 位置并发回请求的数据。滴答滴答。你的 CPU 在等待它完成时什么都不做。

这非常类似于从另一台计算机请求网页。您制定一个 HTTP 请求,发送它并等待 Web 服务器访问内容,制定一个返回数据包并将其发送给您。

如果设备希望访问驻留在 CPU“中”的内存,则几乎完全相同。 (“直接内存访问”只是意味着它不需要中断 CPU 来处理它,但某些东西 [这里的根复合体] 仍然负责解码请求,完成读取并发回结果数据。)

此外,如果 CPU 和设备之间存在中间 PCIe 交换机,这些可能会增加额外的缓冲/排队延迟(就像网络中的交换机或路由器一样)。任何此类延误都会加倍,因为它们是双向发生的。

当然 PCIe 非常快,所以所有这些都在纳秒内发生,但这仍然比“本地”读取慢几个数量级。

关于linux - ioread 中的延迟,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/36431038/

相关文章:

linux - 检查参数是值 X 还是值 Y

real-time - 有什么办法可以将 Redux 中的状态设为 "commit"以释放内存?

c++ - 实时 2D 渲染到系统内存

Android Studio 无法识别我的小米红米 Note 3

python - os.openpty() 在 os.seteuid() 从 root 到用户之后不允许操作

mysql - 如何将 Linux 服务器中的 MySQL 表名更改为不区分大小写?

Linux shell 临时 DNS

recursion - 如何消除这种类型的递归?

android - 无法添加到 micromax funbook P300 平板电脑

windows - 有多少百分比的 Windows 机器支持 OpenGL