Я учусь на RHCSA и меня смущает заявление, с которым я столкнулся в некоторых учебных материалах:

Практического максимального ОЗУ не существует, так как теоретически вы можете запустить 128 ТБ ОЗУ на RHEL 6. Но это только теория. Максимальный объем ОЗУ, поддерживаемый Red Hat на RHEL 6, составляет 16 ГБ в 32-разрядных системах и 2 ТБ в 64-разрядных системах.

Может кто-нибудь объяснить, откуда взялся теоретический предел в 128 ТБ? Я запутался в том, как автор знает, что теоретический предел существует, если RHEL 6 четко определяет другие максимальные пределы. Это только с учетом теоретических ограничений 64-битной архитектуры? Или здесь какая-то другая причина?

Из документации ядра, в Documentation/x86/x86_64/mm.txt:

Virtual memory map with 4 level page tables:

0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm

2 ⁴⁷ байт = 128 ТБ

Короткий ответ

Каждый процесс Linux может использовать не более 128 ТБ виртуальной памяти . Однако это больше, чем ядро ​​Linux может обрабатывать физически . Следовательно, этот предел является теоретическим.

Вероятно, он был выбран произвольно, исходя из предполагаемого допустимого сценария использования «наихудшего случая».

Разработанный ответ

На самом деле вы не можете использовать больше оперативной памяти, чем позволяет ваше аппаратное обеспечение (в наши дни 48 бит = 256 ТБ - обычное явление ), и тогда вы будете ограничены объемом физической памяти, которую может обработать ядро ​​Linux.

Например, в 64-разрядной архитектуре Intel x86 Linux не может использовать более 64 ТБ физической памяти (начиная с версии 2.6.30 , но до этого она составляла 16 ТБ ). Обратите внимание, что RHEL 6 использует ядро 2.6.32 .

В 64-битной архитектуре s390 применяется тот же предел (начиная с 2.6.28 ). Однако если вы используете 32-разрядную версию, ограничение составляет 4 ГБ , но при использовании странного трюка под названием PAE вы можете увеличить его до 64 ГБ (часто используется на x86).

Я думаю, что другие 64-битные архитектуры имеют более низкие пределы.

См. Таблицу ограничений Red Hat для получения дополнительной информации (спасибо Huygens ).

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

Сегодняшние реализации AMD и Intel x86_64 поддерживают только 48-битную адресуемую виртуальную память. Это означает, что ядро ​​может адресовать 2 ^ 48 = 256 ТиБ на виртуальную машину процесса.
Ядро Linux на архитектуре x86_64 разделило адресуемое пространство виртуальной машины на 2, 128 ТиБ для пространства пользователя и 128 ТиБ для пространства ядра. Таким образом, процесс теоретически может адресовать 128 ТБ виртуальной памяти.

Максимум энергозависимой физической памяти, которую может обрабатывать ядро, - это другой аспект, но я не знаю этой информации.

Относительно заявления автора RHCSA

Автор заявления: «Практически не существует максимального ОЗУ, поскольку теоретически вы можете запустить 128 ТБ ОЗУ на RHEL 6». использует неверную или неправильно понятую терминологию. Вот таблица с сайта Red Hat, обобщающая возможности RHEL 3, 4, 5 и 6 . И они четко заявляют: «Максимальное x86_64 виртуального адресного пространства на процесс [...] 128 ТБ [для RHEL 6]»

На той же странице указано, что RHEL 6 поддерживает максимум 2 ТБ / 64 ТБ ОЗУ (физическая энергозависимая память). Я предполагаю, что это означает, что он сертифицирован для максимальной оперативной памяти 2 ТБ и теоретически может достигать 64 ТБ. SLES намного яснее в этом отношении .

Другая причина, по которой он носит теоретический характер, - отсутствие опыта внедрения.

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

Однако размер переменной не единственный предел. Структуры данных и их алгоритмы накладывают свои ограничения. Представьте себе на мгновение линейный обход структуры данных, описывающей каждую страницу размером 4 КБ из этих 128 ТБ. Есть некоторые очевидные ответы: не используйте страницы размером 4 КБ, не используйте линейную структуру данных, не часто обращайтесь к этим структурам данных, максимально разгрузите аппаратное обеспечение. Но есть более тонкая структура данных + ограничения алгоритма, о которых мы не узнаем, пока не столкнемся с ними.

Мы знаем, что если завтра мы волшебным образом обнаружим ПК объемом 128 ТБ и попытаемся загрузить на него Linux, он будет работать ужасно, и, возможно, настолько ужасно, что не запустится. Но исправление алгоритмов тривиально, исправление структур данных - это некоторая работа, но все же гораздо меньше, чем исправление размера широко понятной переменной. Таким образом, мы увидим изменения такого рода по мере увеличения объема памяти.