Памяти контроль размера отображения в виртуальной памяти

Question

Я читал об отображении памяти в следующей ссылку
https://en.wikipedia.org/wiki/Memory-mapped_file
http://en.wikipedia.org/wiki/Memory-mapped_I/O

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

Но не удалось найти преимущества при использовании ввода/вывода с памятью. Какая польза от прямого чтения?

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

Answer 1

Во-первых, понимайте, что сама куча и стек состоят из карт памяти. Каждый процесс userland имеет таблицу карт памяти, и именно так он взаимодействует с менеджером памяти ядра. Карты памяти имеют разные конфигурации и функции. Перейдите к справочной странице mmap(2) для списка настроек.

С файловым файлом mmap ядро ​​управляет кешированием файла в единицах размера страницы (4096 байт) с высокой степенью оптимизации.

Если вы собираетесь читать файл последовательно, то карта памяти не имеет никакого преимущества.

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

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

Загружая файл по требованию таким образом, для многих моделей доступа он будет намного быстрее.

Это также намного более удобно для доступа к файлу в виде области памяти (с использованием арифметики указателя), а затем через интерфейс файла (поиск).

Answer 2

Но почему так же количество времени, необходимое для копирования данных с диска/флэш виртуальной памяти?

Традиционный файл ИО с помощью чтения() системный вызов имел две копии данных. + одна копия с диска в буферный кеш + одна копия из кеша буфера в пользовательский буфер, предоставляемый вызовом read().

Используя mmap(), мы можем напрямую скопировать данные в буфер пользователя & & pagecache, который представляет собой версию буферного кеша mmap() s.

Но есть плюсы и минусы моделей mmap() и read()/write(), а самые современные ОС объединяют как кегет, так и буферный кеш в один унифицированный кеш. Итак, не уверен, сколько из преимуществ производительности у нас есть между этими двумя ...

read() call => системный вызов. Таким образом, в дополнение к вышесказанному, мы буферизовали чтение, то есть fread(), где мы кэшируем некоторые данные файла в потоке в libc. Это уменьшает стоимость системных вызовов для получения большего количества данных, но для новых данных нам нужен системный вызов. Для области mmap стоимость доступа к новым данным - это стоимость ошибки v/s, переход на syscall. Стоимость курса IO остается такой же, как вы намекаете.