Подтвердить что ты не робот

Почему mmap() терпит неудачу с ENOMEM в разрешенном файле 1 ТБ?

Я работал с большими разреженными файлами на openSUSE 11.2 x86_64. Когда я пытаюсь использовать mmap() 1TB разреженный файл, он не работает с ENOMEM. Я бы подумал, что 64-битное адресное пространство будет достаточным для отображения в терабайте, но, похоже, это не так. Экспериментируя далее, файл размером 1 ГБ отлично работает, но файл размером 2 ГБ (и что-то большее) терпит неудачу. Я предполагаю, что может быть настройка где-то, чтобы настроить, но обширный поиск ничего не показывает.

Вот пример кода, который показывает проблему - любые подсказки?

#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <unistd.h>

int main(int argc, char *argv[]) {
    char * filename = argv[1];
    int fd;
    off_t size = 1UL << 40; // 30 == 1GB, 40 == 1TB

    fd = open(filename, O_RDWR | O_CREAT | O_TRUNC, 0666);
    ftruncate(fd, size);
    printf("Created %ld byte sparse file\n", size);

    char * buffer = (char *)mmap(NULL, (size_t)size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if ( buffer == MAP_FAILED ) {
        perror("mmap");
        exit(1);
    }
    printf("Done mmap - returned 0x0%lx\n", (unsigned long)buffer);

    strcpy( buffer, "cafebabe" );
    printf("Wrote to start\n");

    strcpy( buffer + (size - 9), "deadbeef" );
    printf("Wrote to end\n");

    if ( munmap(buffer, (size_t)size) < 0 ) {
        perror("munmap");
        exit(1);
    }
    close(fd);

    return 0;
}
4b9b3361

Ответ 1

Проблема заключалась в том, что ограничение виртуальной памяти для каждого процесса было всего 1,7 ГБ. ulimit -v 1610612736 установите значение 1,5 ТБ, и мой вызов mmap() преуспел. Спасибо, bmargulies, за подсказку попробовать ulimit -a!

Ответ 2

Есть ли какая-то квота для каждого пользователя, ограничивая объем доступной памяти для пользовательского процесса?

Ответ 3

Моя догадка заключается в том, что ядро ​​испытывает трудности с распределением памяти, необходимой ей для поддержания этой памяти. Я не знаю, как пополняемые страницы поддерживаются в ядре Linux (и я полагаю, что большая часть файла будет находиться в состоянии с вывозом в большинстве случаев), но может потребоваться запись для каждой страницы памяти, которую файл занимает в таблице. Поскольку этот файл может быть обработан несколькими процессами, ядро ​​должно не отставать от сопоставления с точки зрения процесса, которое будет сопоставляться с другой точкой зрения, которая будет отображать вторичное хранилище (и включать поля для устройства и местоположения).

Это будет вписываться в ваше адресное пространство, но может не соответствовать (по крайней мере, смежно) в физической памяти.

Если кто-то знает больше о том, как Linux это мне будет интересно узнать об этом.