使物理地址区域中的虚拟地址连续如何提高性能？答案

【问题标题】：How does making the virtual address contiguous in physical address zone improve performance?使物理地址区域中的虚拟地址连续如何提高性能？
【发布时间】：2019-04-23 05:24:28
【问题描述】：

最近我在 dpdk(dpdk.org) 中阅读有关大页面的代码。我看到代码故意使虚拟地址在物理地址区域中连续。具体来说，它首先检查hugepages中是否存在物理上连续的区域，并将物理上的连续区域映射到连续的虚拟地址中。这如何提高性能？

source code 说：

为了保留大量连续的内存，我们使用了 linux 的 hugepage 特性。为此，我们需要安装 hugetlbfs。此代码将在此目录中创建许多文件（每页一个）并将它们映射到虚拟内存中。对于每个页面，我们将检索其物理地址并重新映射它，以便拥有一个虚拟连续区域和一个物理连续区域。

为什么需要重新映射？

【问题讨论】：

linuxgazette.net/155/krishnakumar.html

标签： c linux linux-kernel dpdk huge-pages

【解决方案1】：

将物理上连续的区域映射到连续的虚拟地址。这如何提高性能？

DPDK 需要物理地址和虚拟地址。虚拟地址通常用于加载/存储一些数据。物理地址是用户空间驱动程序向/从设备传输数据所必需的。

例如，我们分配了几个mbufs，虚拟地址为0x41000、0x42000和0x43000。然后我们用一些数据填充它们并将这些虚拟地址传递给 PMD 进行传输。

驱动程序必须将这些虚拟地址转换为物理地址。如果物理页面映射到不连续的虚拟地址空间，要将虚拟地址转换为物理地址，我们需要搜索所有映射。例如，虚拟地址0x41000 可能对应于物理地址0x81000，0x42000 对应于0x16000，而0x43000 可能对应于0x64000。

这种搜索的最佳情况是一次内存读取，最坏的情况是 - 每个缓冲区读取几次内存。

但是，如果我们确定内存区域的虚拟地址和物理地址都是连续的，我们只需在虚拟地址上添加一个偏移量即可获得物理地址，反之亦然。比如虚拟0x41000对应0x81000，虚拟0x42000对应物理0x82000，0x43000——0x83000。

我们从映射中知道的偏移量。这种翻译的最坏情况是突发中每个缓冲区读取一个内存，这对翻译来说是一个巨大的改进。

为什么需要重新映射？

为了将大页面映射到虚拟地址空间，使用了mmap 系统调用。调用的 API 允许为要映射的大页面指定固定的虚拟地址。这允许一个接一个地映射大页面，创建一个连续的虚拟内存区域。比如我们可以在虚拟地址0x200000mmap一个大页面，在虚拟地址0x400000下一个大页面等等。

不幸的是，我们不知道大页面的物理地址，直到它们被映射。所以在虚拟地址0x200000我们可以映射物理地址0x800000，在虚拟地址0x400000——物理0x600000。

但是一旦我们第一次映射这些大页面，我们就知道物理地址和虚拟地址。所以我们需要做的就是以正确的顺序重新映射它们：在虚拟地址0x1200000我们映射物理0x600000，在0x1400000-物理0x800000。

现在我们有一个从虚拟地址0x1200000 和物理地址0x600000 开始的虚拟和物理连续的内存区域。因此，要将这个内存区域中的虚拟地址转换为物理地址，我们只需要从虚拟地址中减去偏移量0x600000，如前所述。

希望这能澄清一下连续内存区域和重新映射的概念。

【讨论】：

嗨，别列斯托夫斯基。完美答案！但是还有一点我不太明白：你说连续映射会带来“一次内存读取”。但是当进程访问这么多内存（多个大页面）时，这将如何发生。在我的理解中，如果进程想要访问内存中的某个元素，它会通过 TLB 或整个页表。我想这就是你所说的“翻译”。因此，如果元素在一个大页面内，则连续映射不起作用。只有元素在两个或多个大页面中，连续映射才会起作用。对吗？
@4va1anch3 TLB 是一个完全不同的故事。无论如何，它仍然存在，大页面通过使用更大的页面和更少的翻译确实提高了 TLB 性能。但是 DPDK 是一个用户空间应用程序，它也需要虚拟到物理地址的转换。所以它是在软件中完成的，而不是使用 TLB。如果我们确定 DPDK 内存区域的所有虚拟地址和物理地址都是连续的，我们可以通过添加一个偏移量在软件中进行转换，如答案中所述。
现在我完全明白了！非常感谢！