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

Копирование этих 16-мегабайтных блоков из области mmap с использованием memcpy не работает, как я ожидал. Похоже, что производительность зависит от размера памяти, зарезервированной во время загрузки (а затем mmap'а в пространство пользователя).http: //www.wurmsdobler.org/files/resmem.zi содержит исходный код модуля ядра, который реализует операцию файла mmap:

<code>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;
}
</code>

и тестовое приложение, которое по сути (с удаленными чеками):

<code>#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;
</code>

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

<code>|      |         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)
</code>

Мои наблюдения:

С первого до второго запуска, memcpy из mmap'ed в malloc'ed, похоже, выиграет от того, что содержимое может быть где-то уже кэшировано.

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

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

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