Почему Debian Linux допускает до 128 ТБ виртуального адресного пространства на процесс, но только 64 ТБ физической памяти?


23

Я только что прочитал здесь :

  • до 128 ТБ виртуального адресного пространства на процесс (вместо 2 ГБ)
  • Поддержка физической памяти 64 ТБ вместо 4 ГБ (или 64 ГБ с расширением PAE)

Почему это? Я имею в виду, поддержка физической памяти ограничена ядром или текущим оборудованием?

Зачем вам вдвое больше виртуальной памяти, чем физической памяти, которую вы можете адресовать?


Вы также можете добавить своп.
Турбьёрн Равн Андерсен

2
это много оперативной памяти ...
dalearn

4
@dalearn - Вы знаете, когда я впервые узнал , что вы могли бы получить расширение памяти банка с коммутацией каналов для 8-битных Micros , которые позволяют им иметь до 4096KB, я сказал точно то же самое ...
Жюль

Ответы:


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.)

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

  • Это позволяет ядру отобразить всю физическую память и оставить место для виртуальных отображений.
  • Помимо сопоставлений физической памяти, существуют сопоставления подкачки, файлов и драйверов устройств.
  • Полезно иметь нераспределенную память местами: защитные страницы для обнаружения переполнения буфера , большие не отображенные зоны из-за ASLR и т. Д.

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

Кто-нибудь может уточнить комментарий @StephenKitt? Я очень заинтересован в понимании этого, но даже после прочтения ссылки, которую он привел, я не понимаю;)
gsi-frank

@ gsi-frank Для ядра удобно постоянно отображать всю физическую память. Таким образом, в адресном пространстве 2 ^ 48 2 47 идет по адресам пользователей, 2 46 идет по адресам ядра, а 2 46 используется для адресации физической памяти.
Жиль "ТАК - перестань быть злым"

@ 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) тоже очень важно. Вы действительно хотите, чтобы виртуальное адресное пространство было на несколько порядков больше объема памяти, который вы будете выделять, чтобы случайные догадки почти наверняка приводили к ловушкам.
R ..

6

Это аппаратные ограничения. Современное оборудование x86_64 / amd64 допускает 48-битные виртуальные адреса и различного размера (зависит от реализации - например, моя рабочая станция здесь поддерживает только 36 бит) физических адресов. Ядро Linux делит виртуальное адресное пространство пополам (используя половину для ядра, половину для пространства пользователя - как это происходит в x86).

Итак, вы получите:

2⁴⁸ байта ÷ 2 = 2⁴⁷ байта = 128 ТиБ

Размер физического адреса часто меньше, потому что он на самом деле физический. Он занимает контакты / контактные площадки, транзисторы, соединения и т. Д. На / в процессоре и трассирует линии на плате. Вероятно, то же самое в чипсетах. Нет смысла поддерживать такое количество оперативной памяти, которое немыслимо в течение срока службы ядра процессора или сокета - все это стоит денег. (Даже с 32 слотами DIMM и DIMM по 64 ГБ в каждом, вы все равно только на 2 ТБ. Даже если емкость DIMM удваивается ежегодно, мы находимся на расстоянии 5 лет от 64 ТБ.

Как отмечает Питер Кордес , люди теперь подключают энергонезависимое хранилище, такое как 3D XPoint, к шине памяти, что делает возможным исчерпание адресного пространства. Более новые процессоры расширили физическое адресное пространство до 48 бит; возможно, вики Debian просто не была обновлена.


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

1
Вы уже можете купить системы с объемом оперативной памяти до 12 ТБ в 96 слотах ( например, четырехпроцессорная система HPC компании Tyan ), поэтому до 64 ТБ может потребоваться меньше пяти лет. И некоторые люди покупают их и снабжают их таким большим количеством оперативной памяти ...
Стивен Китт

@StephenKitt
Хм

Оказывается, вы можете купить системы с 64 ТБ ОЗУ прямо сейчас.
Стивен Китт
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.