Чому Debian Linux дозволяє отримати віртуальний адресний простір до 128TiB за процес, але лише 64TiB фізичну пам'ять?


23

Я щойно прочитав тут :

  • до 128TiB віртуального адресного простору за процес (замість 2GiB)
  • Підтримка фізичної пам'яті 64TiB замість 4GiB (або 64GiB з розширенням PAE)

Чому так? Я маю на увазі, що підтримка фізичної пам'яті обмежена ядром або поточним обладнанням?

Навіщо вам потрібно вдвічі більше простору віртуальної пам’яті, ніж фізична пам’ять, до якої ви дійсно можете звертатися?


Ви також можете додати своп.
Thorbjørn Ravn Andersen

2
це багато оперативної пам’яті…
dalearn

4
@dalearn - ви знаєте, коли я вперше дізнався, що ви можете отримати розширення пам’яті з комутацією банку для 8-бітових мікросхем, що дозволяють їм мати до 4096 КБ, я сказав саме те саме ...
Jules

Відповіді:


35

Ці обмеження не походять від Debian або Linux, вони надходять із апаратного забезпечення. Різні архітектури (процесор і шина пам'яті) мають різні обмеження.

На поточних процесорах x86-64 ПК MMU дозволяє отримати 48 біт віртуального адресного простору . Це означає, що адресний простір обмежений 256 ТБ. За допомогою одного біта для розрізнення адрес ядра від адрес користувача, що залишає 128 ТБ для адресного простору процесу.

У поточних процесорах x86-64 фізичні адреси можуть використовувати до 48 біт , а це означає, що ви можете мати до 256 ТБ. Ліміт прогресивно підвищувався з моменту введення архітектури amd64 (з 40 біт, якщо я правильно пам'ятаю). Кожен біт адресного простору коштує певної логіки проводки та декодування (що робить процесор дорожчим, повільнішим та гарячим), тому виробники апаратних засобів мають стимул зменшити розмір.

Linux дозволяє лише фізичним адресам збільшити до 2 ^ 46 (тому у вас може бути до 64 ТБ), оскільки він дозволяє повністю відобразити фізичну пам'ять у просторі ядра. Пам’ятайте, що є 48 біт адресного простору; один біт для ядра / користувача залишає 47 біт для адресного простору ядра. Половина цього максимум звертається до фізичної пам'яті безпосередньо, а інша половина дозволяє ядру відображати все необхідне. (Linux може впоратися з фізичною пам'яттю, яка не може бути відображена в повному обсязі одночасно, але це вводить додаткові складності, тому це робиться лише на платформах, де це потрібно, наприклад x86-32 з PAE і armv7 з LPAE.)

Корисно, щоб віртуальна пам'ять була більшою, ніж фізична пам'ять з кількох причин:

  • Це дозволяє ядру відображати всю фізичну пам'ять і залишати місця для віртуальних карт.
  • Окрім відображень фізичної пам'яті, є відображення swap, файлів та драйверів пристроїв.
  • Корисно мати незроблену пам'ять у місцях: сторожові сторінки для лову переповнення буфера , великі незмінені зони через ASLR тощо.

9
46-бітове обмеження фізичної пам'яті пов'язане з картою пам'яті Linux : воно включає повне відображення фізичної пам'яті в просторі ядра, а це означає, що фізична пам'ять може відповідати лише чверті доступного адресного простору.
Стівен Кітт

Чи може хтось детальніше зупинитися на коментарі @StephenKitt? Мені дуже цікаво зрозуміти це, але навіть після прочитання посилання, яку він цитував, я цього не розумію;)
gsi-frank

@ gsi-frank Ядро зручно мати всю фізичну пам’ять постійно. Так, у адресному просторі 2 ^ 48, 2 ^ 47 переходить до адрес користувачів, 2 ^ 46 - до адрес ядра, а 2 ^ 46 - до адреси фізичної пам'яті.
Жил 'SO- перестань бути злим'

@ gsi-frank Якщо ви можете отримати копію класичної книги " Розвиток власної 32-бітної операційної системи ", вона поглиблюється значною причиною того, чому автор прийняв подібне рішення для власної ОС (у такому випадку, поділ віртуального адресного простору 4GiB 80386 на сегмент ядра 2GiB, який містить відображення фізичної оперативної пам'яті 1GiB та користувацький сегмент 2GiB). Кожен, хто зацікавлений у внутрішніх справах ОС, мабуть, прочитає його - він забезпечує повний дизайн досить простий для розуміння, але достатньо просунутий, щоб бути корисним ядром ОС.
Жуль

Оскільки версія 4.13 ядра, x86-64 (та деякі інші архітектури) можуть бути побудовані з п'ятирівневими таблицями сторінок , які збільшують адресний простір на x86-64 до 52 біт для фізичної оперативної пам’яті та 57 біт для віртуальної (4 PiB / 128 ПіБ). Зауважте, що карта пам'яті в просторі ядра вводить проблеми безпеки, тому це може змінитися найближчим часом.
Стівен Кітт

9

Я не знаю чому, але я можу придумати сім причин, чому було б корисно підтримувати вдвічі більше адресного простору, ніж фізична пам'ять.

  1. Перший полягає в тому, що ви можете запускати додатки, які потребують додаткової пам’яті, навіть якщо це означає заміну на диск.
  2. Макети чистішої пам’яті для використання пам'яті розділів. Наприклад, ОС може приймати адреси з більшим числом і залишати адреси з меншими номерами для додатків, щоб зробити розділення більш чистим.
  3. Рандомізація розміщення адресного простору трохи ефективніша.
  4. Позначення сторінок виконуваним може означати залишкову пам'ять.
  5. Введення / виведення на карту пам'яті.
  6. Розподіл пам’яті простіше: можна виділити більші шматки одночасно.
  7. Зменшення фрагментації пам'яті

1
Спасибі! 1) настільки очевидний і основний, що я збентежений за запитання;)
gsi-frank

2
(3) теж дуже важливий. Вам дуже потрібен віртуальний адресний простір, який на порядок більший, ніж об'єм пам'яті, який ви будете виділяти, так що випадкові здогади майже напевно призводять до пасток.
Р ..

6

Це обмеження обладнання. Поточне обладнання x86_64 / amd64 дозволяє 48-бітові віртуальні адреси та різний розмір (залежить від реалізації, наприклад, моя робоча станція підтримує лише 36 біт) фізичні адреси. Ядро Linux розділяє віртуальний адресний простір навпіл (використовуючи половину для ядра, половину для простору користувачів - як і x86).

Отже, ви отримуєте:

2⁴⁸ байт ÷ 2 = 2⁴⁷ байт = 128 TiB

Фізичний розмір адреси часто менший, оскільки він насправді фізичний. Він займає штирі / колодки, транзистори, з'єднання тощо, в / в процесорі та сліди на платі. Напевно, теж саме в чіпсетах. Немає сенсу підтримувати кількість оперативної пам’яті, яка немислима протягом тривалості дизайну ядра процесора або сокета - всі ці речі коштують грошей. (Навіть з 32 слотами DIMM і 64 Гбіт DIMM у кожному, ви все ще лише 2TiB. Навіть якщо потужність DIMM вдвічі збільшується, ми за 5 років від 64TiB.

Як зазначає Пітер Кордес , зараз люди приєднують енергонезалежний накопичувач, такий як 3D XPoint, до шини пам’яті, завдяки чому не вистачає адресного простору. Нові процесори розширили фізичний адресний простір до 48 біт; можливо, вікі Debian просто не оновлювались.


Енергонезалежне сховище, підключене безпосередньо до шини пам'яті (наприклад, 3D XPoint), стає предметом, і це може значно збільшити попит на фізичний адресний простір в найближчі кілька років (оскільки він щільніше, ніж DRAM, і корисно мати його навантаження на човні) у більшій кількості випадків, ніж корисно мати вантажі оперативної пам'яті). Див. Zdnet.com/article/the-non-volatile-memory-revolution для не дуже технічної статті (або Google для кращих матеріалів). Intel Skylake підтримує його з її clflushі clflushoptінструкціями.
Пітер Кордес

1
Ви вже можете придбати системи з об’ємом оперативної пам’яті до 12 ТБ в 96 слотів (наприклад , чотириразова система HPC від Тянь ), тож 64TiB може бути менше, ніж за п’ять років. А дехто купує їх і підлаштовує стільки оперативної пам'яті ...
Стівен Кітт

@StephenKitt Хм, це нормально, оскільки потужність DIMM удвічі перевищує 3 роки 😁
derobert

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.