Насколько умный Mmap? - PullRequest
       5

Насколько умный Mmap?

3 голосов
/ 26 марта 2012

mmap может использоваться для совместного использования памяти только для чтения между процессами, уменьшая объем памяти:

  1. обрабатывает файл P1 mmap s, использует отображенную память -> данные загружаются в RAM
  2. обрабатывает P2 mmap s файл, использует отображенную память -> ОС повторно использует ту же память

Но как насчет этого:

  1. обрабатывает файл P1 mmap s, загружает его в память и завершает работу.
  2. другой процесс P2 mmap s тот же файл , обращается к памяти, которая все еще горячая от доступа P1.

Данные снова загружаются с диска? Достаточно ли умна ОС для повторного использования виртуальной памяти, даже если «счетчик mmap» временно упал до нуля?

Отличается ли поведение между разными ОС? (Меня больше всего интересует Linux / OS X)

РЕДАКТИРОВАТЬ: В случае, если ОС недостаточно умна - поможет ли это, если существует один «фоновый процесс», сохраняющий файл mmap ed, чтобы он никогда не покидал адресное пространство хотя бы одного процесса?

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

РЕДАКТИРОВАТЬ2: Я вижу ответы, описывающие совершенно не относящиеся к делу моменты в большой длине. Чтобы повторить мысль - могу ли я полагаться на Linux / OS X, чтобы не перезагружать данные, которые уже находятся в памяти, из предыдущих обращений к страницам в пределах mmap ed сегментов памяти, даже если конкретный регион больше не mmap ed любым процессом?

Ответы [ 2 ]

7 голосов
/ 26 марта 2012

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

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

В двух сценариях из вашего вопроса, попробуйте вставить шаг между шагами 1 и 2:

  • 1.5. другой процесс выделяет и использует большой объем памяти -> файл mmap ed удаляется из памяти, чтобы освободить место.

В этом случае содержимое файла, вероятно, придется перезагружать в память, если оно снова отображается и снова используется на шаге 2.

против

  • 1,5. ничего не происходит -> содержимое файла mmap ed хранится в памяти.

В этом случае содержимое файла не нужно перезагружать на шаге 2.

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

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

3 голосов
/ 26 марта 2012

Второй процесс, вероятно, находит данные из первого процесса в буферном кеше . Таким образом, в большинстве случаев данные не будут загружены снова с диска. Но поскольку буферный кеш является кешем, нет никаких гарантий, что страницы не будут удалены между ними.

Вы можете запустить третий процесс и использовать mmap (2) и mlock (2) для исправления страниц в оперативной памяти. Но это, вероятно, вызовет больше проблем, чем оно того стоит.

Linux заменил буферный кеш UNIX на кеш страниц . Но принцип все тот же. Эквивалент Mac OS X называется Унифицированный буферный кэш (UBC) .

...