Почему mmap() быстрее, чем последовательный IO?

Ответ 1

Я слышал (где-то читал в интернете), что mmap() работает быстрее, чем последовательный ввод-вывод. Это правильно? Если да, то почему это быстрее?

Это может быть - есть плюсы и минусы, перечисленные ниже. Если у вас действительно есть причина для заботы, всегда ставьте оба теста.

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

1) mmap() не читает последовательно. 2) mmap() должен извлекать данные с самого диска так же, как read() 3) Отображаемая область не является последовательной, поэтому нет DMA (?).

Таким образом, mmap() должен быть на самом деле медленнее, чем read() из файла? Какие из моих предположений выше неверны?

1) неверно... mmap() назначает область виртуального адресного пространства, соответствующую содержимому файла... каждый раз, когда осуществляется доступ к странице в этом адресном пространстве, обнаруживается, что физическое ОЗУ поддерживает виртуальные адреса, и соответствующее содержимое диска сбивается в эту оперативную память. Итак, порядок, в котором выполняется чтение с диска, соответствует порядку доступа. Это "ленивый" механизм ввода/вывода. Если, например, вам необходимо проиндексировать огромную хеш-таблицу, которая должна была считываться с диска, то mmap файла и начало доступа означают, что дисковый ввод-вывод не выполняется последовательно и, следовательно, может привести к более длительному истекшему времени. до тех пор, пока весь файл не будет считан в память, но пока это происходит, поиски выполняются успешно, и может быть предпринята зависимая работа, и если части файла никогда не нужны, они не читаются (учитывают детализацию страниц диска и памяти, и что даже при использовании отображения памяти многие операционные системы позволяют вам указывать некоторые советы по повышению производительности/эффективности памяти относительно запланированных шаблонов доступа, чтобы они могли активно читать вперед или более агрессивно освобождать память, зная, что вы вряд ли вернетесь к ней).

2) абсолютно верно

3) "Отображаемая область не является последовательной" является расплывчатым. Области памяти отображаются "непрерывно" (последовательно) в виртуальном адресном пространстве. Мы обсуждали последовательный дисковый ввод/вывод выше. Или вы думаете о чем-то еще? В любом случае, в то время как страницы подвергаются сбоям, они действительно могут передаваться с использованием DMA.

Кроме того, существуют другие причины, по которым отображение памяти может превзойти обычный ввод-вывод:

• там меньше копирования:
  • часто подпрограммы на уровне ОС и библиотеки пропускают данные через один или несколько буферов до того, как они достигают буфера, указанного приложением, приложение затем динамически распределяет хранилище, а затем копирует из буфера ввода-вывода в это хранилище, чтобы данные могли использоваться после завершения чтения файла
  • отображение памяти позволяет (но не форсирует) использование на месте (вы можете просто записать указатель и, возможно, длину)
    • дальнейший доступ к данным на месте увеличивает риск перестановки позже: карта файл/память может быть более многословной, чем структуры данных, в которые она может быть проанализирована, поэтому шаблоны доступа к данным в ней могут иметь больше задержек для отказа в большем количестве страниц памяти
• Отображение памяти может упростить задачу синтаксического анализа приложения, позволяя приложению обрабатывать все содержимое файла как доступное, а не беспокоиться о том, когда читать другой буфер полностью
• приложение больше полагается на мудрость ОС по количеству страниц, находящихся в физической памяти в любой момент времени, эффективно разделяя кэш-память прямого доступа с приложением
• как отмечают доброжелатели ниже, "используя отображение памяти, вы обычно используете меньше системных вызовов"
• если несколько процессов обращаются к одному и тому же файлу, они должны иметь возможность совместно использовать физические страницы поддержки

Также причины, почему mmap может быть медленнее, - читает Торвальдс пост здесь, который говорит о mmap:

... настольные игры вместе с ошибкой (и даже просто пропуском TLB) легко превышают стоимость копирования страницы в хорошем потоковом режиме...

И из другого его поста:

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

• сбой страницы стоит дорого. Это то, как отображение заполняется, и это довольно медленно.

FWIW, в последний раз, когда это возникало у меня на работе, ввод с отображением памяти был на 80% быстрее, чем fread и др. Для чтения двоичных записей базы данных в частной базе данных, на 64-битном Linux с ~ 170 ГБ файлами.

Ответ 2

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

Ответ 3

"Быстрее" в абсолютных выражениях не существует. Вам нужно будет указать ограничения и обстоятельства.

mmap() не читается последовательно.

что заставляет вас думать об этом? Если вы действительно получаете доступ к сопоставленной памяти последовательно, система обычно извлекает страницы в указанном порядке.

mmap() должен извлекать из самого диска тот же самый, что и read() делает

конечно, но ОС определяет время и размер буфера

Отображаемая область не является последовательной - поэтому нет DMA (?).

см. выше

Что помогает mmap в том, что дополнительный буфер пространства пользователя не задействован, "чтение" происходит там, где ядро ​​ОС соответствует требованиям и может быть оптимизировано в кусках. Это может быть преимуществом в скорости, но в первую очередь это просто интерфейс, который проще в использовании.

Если вы хотите узнать о скорости для конкретной установки (аппаратное обеспечение, ОС, образец использования), вам нужно будет измерить.