В системной памяти ... в частности, разница между `tmpfs,` `shm,` и `largepages…`

В последнее время мне было любопытно узнать о различных файловых системах, основанных на памяти ядра Linux.

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

В конечном счете, я думаю, что хотел бы смонтировать пригодную для использования файловую систему, hugepages,хотя некоторые легкие исследования (и все же более легкие попытки) привели меня к мысли, что это rewritable hugepage mountне вариант. Я ошибаюсь? Какая механика играет здесь?

Также относительно hugepages:

     uname -a
3.13.3-1-MANJARO \
#1 SMP PREEMPT \
x86_64 GNU/Linux

    tail -n8 /proc/meminfo
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:     8223772 kB
DirectMap2M:    16924672 kB
DirectMap1G:     2097152 kB

(Вот полнотекстовые версии / proc / meminfo и / proc / cpuinfo )

Что происходит в вышесказанном? Я уже распределяю hugepages?Есть ли разница между DirectMapстраницами памяти иhugepages?

Обновление После небольшого подталкивания от @Gilles я добавил еще 4 строки выше, и кажется, что должна быть разница, хотя я никогда не слышал о том, DirectMapчтобы потянуть это tailвчера ... может быть DMIили что-то?

Еще немного ...

В случае неудачи с hugepagesпопыткой выполнить резервное копирование на жесткий диск любых файлов изображений, каковы риски монтирования циклов из-за того, что tmpfs?моя файловая система - swappedнаихудший сценарий? Я понимаю, tmpfsчто кэш смонтированной файловой системы - может ли мой монтированный зацикленный файл выдаваться из памяти? Могу ли я принять смягчающие меры, чтобы этого избежать?

Последнее - что именно shm,? Чем он отличается от или включает hugepagesилиtmpfs?

Там нет разницы между tmpfs и shm. tmpfs - это новое имя для shm. shm означает SHaredMemory.

Смотрите: Linux tmpfs .

Основная причина, по которой tmpfs используется даже сегодня, - это комментарий в моем / etc / fstab на моей коробке gentoo. КСТАТИ Хром не будет строить с отсутствующей линией:

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for 
# POSIX shared memory (shm_open, shm_unlink). 
shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0 

который вышел из документации ядра Linux

Цитирование:

tmpfs имеет следующие применения:

1) Всегда есть внутренняя монтировка ядра, которую вы вообще не увидите
. Это используется для общих анонимных сопоставлений и общей
памяти SYSV .

Это монтирование не зависит от CONFIG_TMPFS. Если CONFIG_TMPFS не установлен, видимая пользователем часть tmpfs не является сборкой. Но внутренние
механизмы всегда присутствуют.

2) glibc 2.2 и выше ожидает монтирования tmpfs в / dev / shm для
разделяемой памяти POSIX (shm_open, shm_unlink). Добавление следующей
строки в / etc / fstab должно позаботиться об этом:

tmpfs / dev / shm tmpfs по умолчанию 0 0

Не забудьте создать каталог, в который вы собираетесь монтировать tmpfs, если это необходимо.

Это монтирование не требуется для разделяемой памяти SYSV. Для этого используется внутреннее
крепление. (В версиях ядра 2.3 было
необходимо смонтировать предшественника tmpfs (shm fs) для использования
общей памяти SYSV )

3) Некоторые люди (включая меня) считают очень удобным монтировать его,
например, в / tmp и / var / tmp и иметь большой раздел подкачки. И теперь
монтирование цикла файлов tmpfs работает, поэтому mkinitrd, поставляемый большинством
дистрибутивов, должен успешно работать с tmpfs / tmp.

4) И, вероятно, многое другое, я не знаю о :-)

У tmpfs есть три варианта монтирования:

size: предел выделенных байтов для этого экземпляра tmpfs. По умолчанию половина вашей физической памяти без подкачки. Если вы увеличите размер экземпляров tmpfs, машина будет заблокирована, поскольку обработчик OOM не сможет освободить эту память.
nr_blocks: такой же, как размер, но в блоках PAGE_CACHE_SIZE.
nr_inodes: максимальное количество inode для этого экземпляра. Значение по умолчанию составляет половину от количества страниц физической памяти или (на компьютере с высоким значением) количество страниц с низким объемом памяти, в зависимости от того, что меньше.

Из прозрачного документа Hugepage Kernel Doc:

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

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

Новый комментарий после выполнения некоторых расчетов:

Размер огромной страницы: 2
МБ Используемые огромные страницы: Нет / Выкл, о чем свидетельствуют все 0, но включено, как указано выше, 2 МБ.
DirectMap4k: 8,03 ГБ
DirectMap2M: 16,5
ГБ DirectMap1G: 2 ГБ

Используя приведенный выше параграф, касающийся оптимизации в THS, похоже, что 8 ГБ вашей памяти используются приложениями, работающими с использованием malloc 4 КБ, 16,5 ГБ было запрошено приложениями, использующими malloc 2 МБ. Приложения, использующие mallocs из 2M, имитируют поддержку HugePage, выгружая секции 2M в ядро. Это предпочтительный метод, потому что как только ядро ​​освобождает malloc, память освобождается для системы, в то время как монтирование tmpfs с использованием largepage не приведет к полной очистке, пока система не будет перезагружена. Наконец, самая простая, у вас было 2 открытых / запущенных программы, которые запрашивали malloc 1 Гб

Для тех из вас, кто не знает, что malloc - это стандартная структура в C, обозначающая ALLOCation в памяти. Эти расчеты служат доказательством того, что корреляция OP между DirectMapping и THS может быть правильной. Также обратите внимание, что монтирование HUGEPAGE ONLY fs приведет только к увеличению на 2 МБ, тогда как разрешение системе управлять памятью с использованием THS происходит в основном в блоках по 4 Кб, что означает, что с точки зрения управления памятью каждый вызов malloc сохраняет систему 2044 Кб (2048-4 ) для какого-то другого процесса, чтобы использовать.

Для решения проблемы «DirectMap»: ядро ​​имеет линейное («прямое») отображение физической памяти , отдельное от виртуальных отображений, выделенных каждому пользовательскому процессу.

Ядро использует максимально возможные страницы для этого отображения, чтобы уменьшить нагрузку на TLB.

DirectMap1G отображается, если ваш процессор поддерживает страницы объемом 1 Гб (Барселона и далее; некоторые виртуальные среды отключают их), и если он включен в ядре - по умолчанию включено для 2.6.29+.

Там нет никакой разницы между shmи tmpfs(на самом деле, tmpfsэто только новое имя прежнего shmfs). hugetlbfsэто tmpfsфайловая система на основе, которая выделяет свое пространство из огромных страниц ядра и требует дополнительной конфигурации (как это использовать, описано в Documentation / vm / hugetlbpage.txt ).