Низкая производительность memcpy в пользовательском пространстве для mmap& #39;ed физической памяти в Linux

Из 192 ГБ ОЗУ, установленных на моем компьютере, у меня есть 188 ГБ ОЗУ объемом более 4 ГБ (по аппаратному адресу 0x100000000 ), зарезервированному ядром Linux во время загрузки (mem=4G memmap =188G$4G ). Модули ядра сбора данных накапливают данные в этой большой области, используемой в качестве кольцевого буфера, используя DMA. Приложение пользовательского пространства mmap отображает этот кольцевой буфер в пользовательское пространство, а затем копирует блоки из кольцевого буфера в текущее местоположение для обработки, как только они будут готовы.

Копирование этих 16-мегабайтных блоков из области mmap с помощью memcpy работает не так, как я ожидал. Похоже, что производительность зависит от размера памяти, зарезервированной во время загрузки (и позднее отображённой в пользовательское пространство ).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;

Я провел тесты memcpy для данных размером 16 МБ блок для разных размеров зарезервированной оперативной памяти (resmem _length )в Ubuntu 10.04.4, Linux 2.6.32,на SuperMicro 1026GT -TF -FM109:

|      |         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. От первого до второго запуска memcpy из mmap'ed в malloc'ed, похоже, выигрывает от того, что содержимое уже может быть где-то кэшировано.

2. Наблюдается значительное снижение производительности по сравнению с объемом >64 ГБ, что заметно как при использовании memcpy.

Я хотел бы понять, почему это так. Возможно, кто-то из группы разработчиков ядра Linux подумал, что :64 Гбайт должно быть достаточно для всех (это звонит в колокол?)

С уважением, питер