Когда я должен использовать mmap для доступа к файлам?

Одна область, где я нашел mmap(), чтобы не быть преимуществом, - это чтение небольших файлов (до 16K). Накладные расходы на ошибку страницы для чтения всего файла были очень высокими по сравнению с простое выполнение одного системного вызова read(). Это связано с тем, что ядро ​​иногда может усвоить прочитанное полностью в вашем временном фрагменте, то есть ваш код не отключается. С ошибкой страницы казалось более вероятным, что другая программа будет запланирована, что приведет к большей задержке работы файла.

mmap имеет то преимущество, когда у вас есть случайный доступ к большим файлам. Другим преимуществом является то, что вы обращаетесь к нему с операциями памяти (memcpy, арифметикой указателей), не беспокоясь о буферизации. Обычный ввод-вывод иногда может быть довольно сложным при использовании буферов, когда у вас есть структуры, большие, чем ваш буфер. Код для обработки, который часто трудно получить, часто бывает проще. Это говорит о том, что при работе с mmap есть определенные ловушки. Как уже упоминалось, mmap достаточно дорогостоящий, поэтому его следует использовать только для заданного размера (от машины к машине).

Для чистого последовательного доступа к файлу это также не всегда лучшее решение, хотя соответствующий вызов madvise может уменьшить проблему.

Вы должны быть осторожны с ограничениями на выравнивание вашей архитектуры (SPARC, itanium), с IO чтения/записи, буферы часто правильно выравниваются и не ловутся при разыменовании литого указателя.

Вы также должны быть осторожны, чтобы не получить доступ за пределами карты. Это легко осуществить, если вы используете строковые функции на своей карте, и ваш файл не содержит \0 в конце. Он будет работать большую часть времени, когда размер вашего файла не будет кратным размеру страницы, поскольку последняя страница заполнена 0 (отображаемая область всегда имеет размер, равный кратности вашего размера страницы).

Карта памяти имеет потенциал для огромного преимущества по сравнению с традиционным IO. Он позволяет операционной системе считывать данные из исходного файла, когда затрагиваются страницы в файле с отображением памяти. Это работает путем создания страниц с ошибками, которые ОС обнаруживает, а затем ОС автоматически загружает соответствующие данные из файла.

Это работает так же, как механизм подкачки и обычно оптимизируется для высокоскоростного ввода-вывода, считывая данные о границах и размерах страницы системы (обычно 4K) - размер, для которого оптимизированы большинство кэшей файловой системы.

В дополнение к другим приятным ответам, цитата из системное программирование Linux, написанная экспертом Google Робертом Любом:

Преимущества mmap( )

Манипулирование файлами через mmap( ) имеет несколько преимуществ перед стандартные read( ) и write( ) системные вызовы. Среди них:

• Чтение и запись в файл с отображением памяти позволяет избежать посторонняя копия, возникающая при использовании системы read( ) или write( )вызовы, где данные должны быть скопированы в буфер пользователя и из него.

• Помимо любых потенциальных сбоев страниц, чтение и запись в файл с отображением памяти не несет никакого системного вызова или контекстного переключателя накладные расходы. Это так же просто, как доступ к памяти.

• Когда несколько процессов сопоставляют один и тот же объект в памяти, данные распределяются между всеми процессами. Только для чтения и совместного доступа к записи сопоставления разделяются полностью; частные записи, доступные для записи, имеют их еще не-COW (копировать-на-запись) страницы.

• Поиск вокруг отображения включает тривиальные манипуляции с указателями. Системный вызов lseek( ) не требуется.

По этим причинам mmap( ) является разумным выбором для многих приложений.

Недостатки mmap( )

При использовании mmap( ) следует иметь в виду несколько моментов:

• Отображения памяти всегда представляют собой целое число страниц. Таким образом, разница между размером файла резервной копии и целое число страниц "потеряно" в качестве незаполненного пространства. Для небольших файлов значительная часть картирования может быть потрачена впустую. Например, с 4 КБ страниц, 7-байтовое отображение отходов составляет 4 089 байт.

• Отображения памяти должны вписываться в адресное пространство процесса. С 32-разрядным адресным пространством очень большое количество отображений различного размера может привести к фрагментации адресного пространства, что затрудняет найти большие свободные смежные области. Эта проблема, конечно, много менее очевидным с 64-разрядным адресным пространством.

• В создании и обслуживании сопоставлений памяти и связанных структур данных внутри ядра возникают накладные расходы. Эти накладные расходы как правило, устраняется устранением двойной копии, упомянутой в в предыдущем разделе, особенно для более крупных и часто используемых файлы.

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