Linux DAX (прямой доступ) Подробнее

Прежде чем обсуждать ваш пример, небольшая оговорка: это несколько упрощенная версия реальности , Есть много крайних случаев и исключений, которые я не объясняю, но этого должно быть достаточно, чтобы вы поняли, что происходит...

Блочные устройства

Что вас смущает, так это неразборчивое использование «блочных устройств». Термин «устройство». Блочными устройствами обычно являются жесткие диски, компакт-диски, твердотельные накопители... Как следует из самого названия, вы не можете читать/записывать отдельные байты на эти устройства, вам необходимо записывать их блоками (обычно размером 512 байт).

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

Итак, вы видите, что с такими устройствами довольно сложно (если не невозможно) не использовать основную память (DRAM), так как их работа включает операции прямого доступа к памяти и тому подобное. В этих случаях DAX устраняет некоторые накладные расходы, связанные с доступом к данным, но не более того.

Энергонезависимая память (NVM) формата DIMM*

Однако недавно на рынке появились энергонезависимые запоминающие устройства (NVM) формата DIMM*. Эти устройства сопоставляют все свое содержимое с адресным пространством процессора и, следовательно, могут быть доступны напрямую процессором с помощью инструкций сохранения и загрузки. Ядру даже не нужно знать, что к этим устройствам осуществляется доступ: во всех смыслах это похоже на то, как если бы процесс обращался к обычной странице памяти, поддерживаемой DRAM.

*Формат DIMM был лишь одним из примеров. Есть также некоторые другие существующие интерфейсы, такие как PCI, которые делают именно это...

Запутанная часть

Здесь возникает путаница... До недавнего времени "устройство хранения" было практически синонимом "блочного устройства".Ядро Linux распознает эти новые NVM как устройства хранения/блочные устройства и обрабатывает их соответствующим образом, создавая запись в /dev так же, как, например, для SSD. (Если у вас нет одного из этих устройств с поддержкой NVM, вы можете имитировать это, указав, что данный диапазон памяти вашей обычной DRAM должен обрабатываться как NVM. См. здесь для получения дополнительной информации о том, как это сделать. .)

Если вы создадите файловую систему на таком устройстве, оно будет работать так же, как если бы оно использовало обычный жесткий диск. Он попытается повысить производительность за счет кэширования содержимого в DRAM. Что делают файловые системы с поддержкой DAX, так это избегают создания кешей, которые должны были ускорить доступ, но в этих случаях, скорее всего, ухудшили бы производительность.

Даже если ядро ​​или его модули хранятся в файловой системе, поддерживает DAX на блочном устройстве, которое поддерживает DAX, они по-прежнему будут копируется в ОЗУ.

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

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

Взгляните на проекты Pmem.io от Intel и Atlas от HP. Это программные интерфейсы, созданные специально для такого рода вещей.

Теперь о вашем примере:

# mount -t ramfs -o dax,size=8m ext2 /ramdisk
# mount
rootfs on / type rootfs (rw,size=59124k,nr_inodes=14781)
proc on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
ext2 on /ramdisk type ramfs (rw,relatime,dax,size=8m)
#

Вы не создаете файловую систему EXT2 с поддержкой оперативной памяти. Вы создаете файловую систему с поддержкой RAM, используя ramfs с фиктивным именем ext2. Не будет никакой разницы, если вы смонтируете его так:

# mount -t ramfs -o dax,size=8m winter_is_coming /ramdisk

Does it keep the.text region in place, but create a copy of.data region?

В любом случае exec()работает так же, как mmap()с MAP_PRIVATE. Страницы отображаются в виртуальном адресном пространстве процессов только для чтения -. Поэтому записи вызывают прерывание по ошибке страницы. Способ обработки этих ошибок страницы описан как Копирование при записи .

В случае DAX виртуальные страницы начинаются как сопоставленные с физическими страницами на устройстве. Но ошибки записи страницы на MAP _PRIVATE скопируют данные страницы на новую страницу в ОЗУ. (Затем отображение процессов обновляется соответствующим образом, и прерванная программная инструкция перезапускается ).

Обратите внимание, что DAX является обобщением XIP, позволяющим выполнять как запись, так и чтение, т. е. MAP _SHARED, а также MAP _PRIVATE. MAP _SHARED можно использовать, например, для файлов базы данных.

На самом деле, .textтакже может быть написано в случае разделяемых библиотек. библиотеки, которые не являются позиционно-независимыми исполняемыми файлами и содержат ссылки на самих себя, нуждаются в обновлении этих ссылок в соответствии с тем, по какому адресу была загружена соответствующая библиотека. Этот процесс называется «переселением». Библиотеки также ссылаются на другие библиотеки, например. библиотека; обновление этих ссылок называется «разрешением символов».

Even if the kernel or its modules are stored on a filesystem that supports DAX on a block device that supports DAX, they will still be copied into RAM.

Модули ядра являются особыми.Они также требуют разрешения символов. Но ядро ​​не использует COW. (В более общем случае он не использует пейджинг по запросу -для своего кода и сегментов данных ). Ошибки страниц внутри ядра фатальны, потому что их обработка может привести к бесконечной рекурсии! Поэтому до -DAX было ясно, что модули ядра необходимо копировать в оперативную память целиком. Код ядра и сегменты данных небольшие; когда DAX был реализован, было бы бесполезно возиться с этим на серверах с адресным хранилищем байтов -.

Само ядро ​​исторически сжато, очевидно, оно распаковано в оперативную память.

Тем не менее, XIP поддерживается для несжатых ядер . Обычно это используется во «встроенной» системе, то есть на довольно ограниченном оборудовании. В этот момент, вероятно, не проблема сделать большую часть необходимого кода встроенной -, в отличие от использования загружаемых модулей.