加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 综合聚焦 > 服务器 > Linux > 正文

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

发布时间:2020-12-14 02:19:02 所属栏目:Linux 来源:网络整理
导读:在我的计算机上安装了192GB RAM,我在启动时由 Linux内核保留了大于4GB(硬件地址为0x100000000)的188GB RAM(mem = 4G memmap = 188G $4G).数据采集??内核模块使用DMA将数据累积到用作环形缓冲区的大区域中.用户空间应用程序mmap将此环形缓冲区放入用户空间,然
在我的计算机上安装了192GB RAM,我在启动时由 Linux内核保留了大于4GB(硬件地址为0x100000000)的188GB RAM(mem = 4G memmap = 188G $4G).数据采集??内核模块使用DMA将数据累积到用作环形缓冲区的大区域中.用户空间应用程序mmap将此环形缓冲区放入用户空间,然后从当前位置的环形缓冲区复制块,以便在它们准备好后进行处理.

使用memcpy从mmap的区域复制这些16MB块不会像我预期的那样执行.看起来性能取决于启动时保留的内存大小(以及后来mmap进入用户空间). http://www.wurmsdobler.org/files/resmem.zip包含实现mmap文件操作的内核模块的源代码:

module_param(resmem_hwaddr,ulong,S_IRUSR);
module_param(resmem_length,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;

我在SuperMicro 1026GT-TF-FM109上的Ubuntu 10.04.4,Linux 2.6.32上对不同大小的保留RAM(resmem_length)进行了16MB数据块的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)

我的观察是:

>从第一次到第二次运行,从mmap到malloc’ed的memcpy似乎有益于内容可能已经被缓存到某个地方.
>从64GB开始,性能显着下降,使用memcpy时都会注意到这一点.

我想明白为什么会这样.也许Linux内核开发人员小组中的某个人认为:对于任何人来说64GB都应该足够了(这会响铃吗?)

亲切的问候,
彼得

解决方法

根据SuperMicro的反馈,性能下降是由NUMA,非均匀内存访问引起的. SuperMicro 1026GT-TF-FM109采用X8DTG-DF主板,内置一个Intel 5520 Tylersburg芯片组,连接两个Intel Xeon E5620 CPU,每个CPU都附带96GB RAM.

如果我将我的应用程序锁定到CPU0,我可以观察不同的memcpy速度,具体取决于保留的内存区域,从而mmap’ed.如果保留的内存区域是非CPU的,那么mmap会在一段时间内完成其工作,并且任何进出“远程”区域的后续memcpy都会消耗更多时间(数据块大小= 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也能产生良好的效果.这在某种程度上与理论相矛盾.

问候,彼得

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读