The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Memory Mapped Files (отображение файлов на память) (mmap gcc ipc file)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: mmap, gcc, ipc, file,  (найти похожие документы)
From: Денис Смирнов <[email protected]> Date: Mon, 4 Jun 2003 13:01:37 +0000 (UTC) Subject: Memory Mapped Files (отображение файлов на память) Оригинал: http://freesource.info/article/3.shtml Memory Mapped Files (отображение файлов на память) Предположим, что наша программа должна прочитать файл размером в несколько сотен мегабайт, и посчитать в нем статистику встречаемости разных символов. Задача выглядит тривиальной - открываем файл, читаем блоками, скажем, по 64Kb (экспериментально подобраная величина, которая часто оказывается оптимальной) и считаем в них статистику. Проще, вроде бы не придумаешь. Можно, конечно, считать сразу весь файл в память, но во-первых памяти может просто не хватить, а во-вторых мы все-таки в многозадачной ОС. А теперь посмотрим что при этом происходит реально для каждого блока - блок данных с диска пересылается в кэш (обычно используя, чтобы не загружать процессор, дабы он мог в это время заняться другими делами), из этого кэша данные копируются в наш буфер, в котором и производится обработка. При этом, разумеется, данные в кэше обычно остаются. То же самое происходит со следующим блоком. В результате некоторое количество блоков просто занимают кэш (мы ведь все равно читам файл последовательно), происходят лишнии операции копирования (которые, в отличии от дисковых, во-первых забирают на себя ресурсы процессора, а во-вторых забивают кэш процессора, тем самым тормозя всю систему в целом). Представим себе, что мы запустили одновременно десяток таких программ. Часть памяти ушла впустую на буферы внутри программ, хотя она нам в этот момент была бы так нужна в качестве дискового кэша, и огромное количество процессорного времени на тупое копирование по многу раз одинаковых данных. Неприятно. В таких случаях на помощь и приходит mmap. Механизм его работы следующий - как только происходит обращение к памяти по указателю, который нам возвратила функция mmap генерируется исключение. Обработчик исключения загружает данные с диска в кэш (если они еще не в кэше) и делает mapping (отображение) кэша на адресное пространство приложения, после чего приложению дается право на чтение этих данных. В том случае, если данные из кэша выгружаются из памяти, то отображение тоже убирается, и как только приложение опять попытается обратиться к этим данным, сгенерируется исключение, и все повторится по новой. Это позволяет программисту вообще не заботиться об оптимизации работы с диском - все это берет на себя механизм виртуальной памяти линукса. В любом случае происходит экономия и памяти, и скорости (за счет отсутствия копирования из кэша в буфер приложения). В случае же обращения к одним и тем же данным несколькими приложениями это особенно заметно. А теперь вернемся к примеру с подсчетом статистики по большому файлу. При попытке обратиться к самому первому байту генерируется исключение, происходит подгрузка в кэш при необходимости и делается mapping. Программа считает статистику по первой странице памяти, после чего опять генерируется исключение, и подгружается вторая. Через некоторое время памяти начнет нехватать, и те блоки памяти, которые дольше всего неиспользовались, начинают заменяться на новые данные. То есть происходит нормальный процесс очистки дискового буфера, который происходил бы и при обычном чтении(!), однако благодаря использования механизмов mmap доступной кэш памяти стало больше (ведь она не тратится на буферы внутри приложений). А теперь что произойдет если я одновременно запущу несколько таких программ - количество сэкономленной памяти будет еще больше, оно будет расти линейно с ростом использования этого механизма, как следствие и больше скорость работы всей системы в целом. Кроме того responsability системы ощутимо повышается - так как нет этих операций копирования больших блоков данных (которые происходят, к тому же, внутри syscall'ов) и чтение с диска производится по факту необходимости данных, а не заранее, что делает поведение системы более "плавным". Ограничения К сожалению, на 32-х битных системах адресное пространство пользовательских приложений ограничено, и обычно не больше 3Gb. В это пространство должно уместится приложение, все загружаемые им so-модули (shared objects), все его данные и mapping'и файлов. Соответственно, если вы хотите работать с большими файлами, то вам придется делать mapping не файла целиком, а отдельных его частей. Это нельзя считать недостатком, ибо обычный read/write метод работы с файлами в подобной ситуации будет гораздо менее эффективен и удобен. Просто если вам необходима работа с файлами очень большого размера, то вам, видимо, придется делать mapping небольших блоков, и работать с ними. See also: Copy-On-Write mmap(2) msync(2) getpagesize(2) Денис Смирнов <[email protected]> 15 Oct 2001

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ RSS ]
  • 1, Никита (??), 17:08, 20/10/2014 [ответить]  
  • +/
    Добрый день! Спасибо за отличную статью! Я новичек в kernel и меня уже второй день мучает вопрос, который я никак нигде не могу нагуглить. На сколько я понял, отображение файла - это чтение данных из него через адрес в виртуальной памяти, без непосредственной загрузки данных в память (только в кэш, а он маленький совсем). То есть, при попытке считать по адресу замэпленного файла, на самом деле происходит чтение из файла.

    Известно, что в Линуксовском процессе все so-шки мапятся в память как раз по описанному механизму. Правильно ли я понимаю, что при чтении инструкции из so-шной библиотеки, каждый (ну или почти каждый) раз идет обращение к файлу (через отображение), то есть к ПЗУ, то есть к жесткому диску, то есть ОЧЕНЬ МЕДЛЕНО. Как-то странно получается, ведь оперативная память на то и сделана, чтобы уменьшить колличество чтений из ПЗУ и ускорить выполнение... Или эта so-шка в начале вся грузится в память (хотя смысл тогда в отображении)... не понимаю... Буду очень признателен за ответ на вопрос)

     
  • 2, Gro (??), 14:28, 22/08/2019 [ответить]  
  • +/
    Не "на буферы" (нет такой формы), а "на буфера".
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру