linux - Linux 中 mmap 物理内存的用户空间中的 memcpy 性能不佳

Question

在我的计算机上安装的 192GB RAM 中，我有超过 4GB 的 188GB RAM(在硬件地址 0x100000000)由 Linux 内核在启动时保留(mem=4G memmap=188G$4G)。数据采集​​内核模块使用 DMA 将数据累积到这个用作环形缓冲区的大区域中。用户空间应用程序将这个环形缓冲区映射到用户空间，然后从当前位置的环形缓冲区复制 block ，以便在它们准备好后进行处理。

使用 memcpy 从 mmap'ed 区域复制这些 16MB block 并没有像我预期的那样执行。似乎性能取决于启动时保留的内存大小(以及后来映射到用户空间)。 http://www.wurmsdobler.org/files/resmem.zip包含实现 mmap 文件操作的内核模块的源代码:

module_param(resmem_hwaddr, ulong, S_IRUSR);
module_param(resmem_length, ulong, S_IRUSR);
//...
static int resmem_mmap(struct file *filp, struct vm_area_struct *vma) {
remap_pfn_range(vma, vma->vm_start,
    resmem_hwaddr >> PAGE_SHIFT,
    resmem_length, vma->vm_page_prot);
return 0;
}

和一个测试应用程序，它本质上是(删除了检查):

#define BLOCKSIZE ((size_t)16*1024*1024)
int resMemFd = ::open(RESMEM_DEV, O_RDWR | O_SYNC);
unsigned long resMemLength = 0;
::ioctl(resMemFd, RESMEM_IOC_LENGTH, &resMemLength);
void* resMemBase = ::mmap(0, resMemLength, PROT_READ | PROT_WRITE, MAP_SHARED, resMemFd, 4096);
char* source = ((char*)resMemBase) + RESMEM_HEADER_SIZE;    
char* destination = new char[BLOCKSIZE];
struct timeval start, end;
gettimeofday(&start, NULL);
memcpy(destination, source, BLOCKSIZE);
gettimeofday(&end, NULL);
float time = (end.tv_sec - start.tv_sec)*1000.0f + (end.tv_usec - start.tv_usec)/1000.0f;
    std::cout << "memcpy from mmap'ed to malloc'ed: " << time << "ms (" << BLOCKSIZE/1000.0f/time << "MB/s)" << std::endl;

我在 Ubuntu 10.04.4、Linux 2.6.32 和 SuperMicro 1026GT-TF-FM109 上针对不同大小的预留 RAM (resmem_length) 对 16MB 数据 block 进行了 memcpy 测试:

|      |         1GB           |          4GB           |         16GB           |        64GB            |        128GB            |         188GB
|run 1 | 9.274ms (1809.06MB/s) | 11.503ms (1458.51MB/s) | 11.333ms (1480.39MB/s) |  9.326ms (1798.97MB/s) | 213.892ms (  78.43MB/s) | 206.476ms (  81.25MB/s)
|run 2 | 4.255ms (3942.94MB/s) |  4.249ms (3948.51MB/s) |  4.257ms (3941.09MB/s) |  4.298ms (3903.49MB/s) | 208.269ms (  80.55MB/s) | 200.627ms (  83.62MB/s)

我的观察是:

1. 从第一次运行到第二次运行，从 mmap'ed 到 malloc'ed 的 memcpy 似乎受益于内容可能已经缓存在某处。

2. 从 >64GB 开始，性能显着下降，这在使用 memcpy 时都可以注意到。

我想了解为什么会这样。也许 Linux 内核开发者小组中的某个人认为:64GB 对任何人来说都应该足够了(这是否敲响了警钟？)

亲切的问候，彼得

Answer 1

根据 SuperMicro 的反馈，性能下降是由于 NUMA，非统一内存访问。 SuperMicro 1026GT-TF-FM109 使用 X8DTG-DF 主板，其核心是一个 Intel 5520 Tylersburg 芯片组，连接到两个 Intel Xeon E5620 CPU，每个 CPU 都有 96GB RAM。

如果我将我的应用程序锁定到 CPU0，我可以观察到不同的 memcpy 速度，具体取决于保留的内存区域并因此映射。如果保留的内存区域不在 CPU 上，那么 mmap 会挣扎一段时间来完成它的工作，并且任何后续往返“远程”区域的 memcpy 都会消耗更多时间(数据 block 大小 = 16MB):

resmem=64G$4G   (inside CPU0 realm):   3949MB/s  
resmem=64G$96G  (outside CPU0 realm):    82MB/s  
resmem=64G$128G (outside CPU0 realm):  3948MB/s
resmem=92G$4G   (inside CPU0 realm):   3966MB/s            
resmem=92G$100G (outside CPU0 realm):    57MB/s   

这几乎是有道理的。只有第三种情况，64G$128，也就是说最上面的64GB也有不错的效果。这在某种程度上与理论相矛盾。

问候，彼得