У системній пам’яті… конкретно різниця між `tmpfs,` `shm,` та 'величезними сторінками ...'

Мене останнім часом цікавить різні файлові системи на основі пам'яті ядра 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. BTW Chromium не будуватиметься при відсутності рядка:

# 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: Максимальна кількість входів для цього примірника. За замовчуванням - це половина кількості ваших фізичних сторінок оперативної пам’яті або (на машині з високим розміром) кількості сторінок оперативної пам’яті з низькою пам’яттю, залежно від того, яка є нижча.

З документа прозорого величезного ядра:

Підтримка прозорої величезної сторінки забезпечує максимальну корисність вільної пам’яті порівняно з підходом до резервування hugetlbfs, дозволяючи використовувати всю невикористану пам'ять як кеш або інші рухомі (або навіть нерухомі об'єкти). Це не вимагає резервування, щоб запобігти поміттю невдач при розподілі величезних сторінок з боку користувачів. Це дозволяє пейджинги та всі інші вдосконалені функції VM бути доступними на величезних сторінках. Він не потребує модифікацій програм, щоб ними скористатися.

Однак додатки можна оптимізувати, щоб скористатися цією функцією, як, наприклад, раніше вони були оптимізовані, щоб уникнути затоплення системних викликів mmap для кожного малока (4 к). Оптимізація користувальницької програми на сьогоднішній день не є обов'язковою, і hgegepaged вже може піклуватися про довговічне розміщення сторінок навіть для величезних невідомих програм, що займаються великою кількістю пам'яті.

Новий коментар після деяких розрахунків:

Розмір HugePage: 2 Мб
Використані HugePages: немає / вимкнено, про що свідчать усі 0, але ввімкнено відповідно до 2 Мб вище.
DirectMap4k: 8.03Gb
DirectMap2M: 16.5Gb
DirectMap1G: 2Gb

Використовуючи вищезазначений абзац щодо оптимізації в THS, схоже, що через 8 Гб вашої пам’яті використовуються додатки, які працюють з маликами 4k, 16,5Gb, запитували програми, що використовують малоки 2M. Програми, що використовують малоки 2М, імітують підтримку HugePage, завантажуючи 2M розділи до ядра. Це кращий метод, тому що після вивільнення malloc ядром пам'ять вивільняється в систему, тоді як монтаж tmpfs за допомогою величезної сторінки не призведе до повного очищення, поки система не перезавантажиться. Нарешті, найпростіша, у вас було відкрито / запущено 2 програми, які вимагали розміру 1 Гбіт

Для тих, хто з вас читає, хто не знає малак, є стандартною структурою на C, яка розшифровується як ALL ALLATION. Ці розрахунки служать доказом того, що співвідношення ОП між DirectMapping та THS може бути правильним. Також зауважте, що встановлення HUGEPAGE ТОЛЬКО fs призведе до лише збільшення приросту в 2 Мб, тоді як дозволити системі керувати пам’яттю за допомогою THS відбувається в основному в 4 к блоках, що означає, що з точки зору управління пам'яттю кожен виклик malloc економить систему 2044k (2048 - 4 ) для використання в іншому процесі.

Для вирішення проблеми "DirectMap": ядро ​​має лінійне ("пряме") відображення фізичної пам'яті , окремо від віртуальних відображень, виділених для кожного користувача процесу.

Ядро використовує найбільші можливі сторінки для цього відображення для зменшення тиску TLB.

DirectMap1G видно, якщо ваш процесор підтримує сторінки 1Gb (Барселона далі; деякі віртуальні середовища їх відключають), а якщо включено в ядрі - за умовчанням увімкнено 2.6.29+.

Ніякої різниці між shmі tmpfs(насправді tmpfsце лише нове ім’я колишнього shmfs). hugetlbfsце tmpfsфайлова система на базі даних, яка виділяє свій простір з величезних сторінок ядра і потребує додаткової конфігурації (як це використовувати пояснюється в Documentation / vm / hugetlbpage.txt ).