Насколько я понимаю, если обычный файл сопоставляется с диапазоном виртуальных адресов, не требуется никакого пространства подкачки. Только MAP_ANONYMOUS может потребоваться некоторое пространство подкачки.
Это зависит от флагов mmap. Если обычный файл сопоставлен с MAP_PRIVATE, то область памяти инициализируется из файла, но не с поддержкой файла. Системе потребуется пространство подкачки для такого сопоставления, если она решит поменять любую из своих страниц.
Итак, правильно ли всегда добавлять флаг MAP_NORESERVE в mmap для обычного файла ?
Это не неверно , чтобы указать MAP_NORESERVE для любого сопоставления. Это просто вопрос того, что вы хотите получить о поведении программы.
Более того, вы, похоже, смотрите на это с неправильной стороны. Если конкретное сопоставление никогда не требует места подкачки, тогда система не зарезервирует для него место подкачки, независимо от флагов. В таком случае не помешает использовать MAP_NORESERVE, но это тоже не поможет, в чем же смысл?
С другой стороны, если вы хотите быть уверены, что отображение не может потерпеть неудачу из-за использования MAP_NORESERVE, тогда наиболее подходящий способ действий - избегать использования этого флага. Вы можете полностью игнорировать его существование, если вы используете sh, и на самом деле вам следует это делать, если вы хотите максимальной переносимости, потому что MAP_NORESERVE - это расширение Linux, не указанное в POSIX.
Обновление:
Насколько я понимаю, вы утверждаете, что можете воспроизводимо наблюдать успешное отображение существующих диапазонов существующих файлов с помощью MAP_SHARED, требующим MAP_NORESERVE. То есть, две такие попытки сопоставления, которые отличаются только тем, указано ли MAP_NORESERVE, дадут вам разные результаты, таким образом, что вы сможете предсказать и надежно воспроизвести.
Я считаю это удивительным, даже сомнительным. Я не ожидаю, что страницы виртуального адресного пространства процесса, которые таблица страниц отображает в существующие области обычного файла, будут иметь какую-либо связь с пространством подкачки, и поэтому я не ожидаю, что система попытается зарезервировать любое пространство подкачки для таких страниц, когда он устанавливает отображение, несмотря на флаги. Если вы действительно наблюдаете другое поведение, я бы отнес это к ошибке библиотеки или ядра, о которой вам следует сообщить о проблеме.
Рассмотрим, например, руководство по GNU lib c, в котором явно сказано, что отображение памяти может быть больше, чем физическая память и пространство подкачки , но вообще не документировать Linux -specifi c MAP_NORESERVE.
С учетом сказанного, опять же, это не неверно (на Linux), чтобы указать MAP_NORESERVE для любого данного отображения памяти. Я ожидаю, что это будет бессмысленно для MAP_SHARED отображения существующей области обычного файла, однако, поэтому я не считаю хорошим, а тем более лучшим, практиковать регулярное использование этого флага для таких отображений. С другой стороны, если указание этого флага работает вокруг ошибки библиотеки или ядра, которая иначе мешает установлению определенных отображений, то я не вижу особой причины избегать этого, но я ожидаю, что каждое такое использование будет сопровождаться документальным комментарием, объясняющим, почему этот флаг используется.