Есть ли будущее у NaN-бокса и теговых указателей на 64-битных платформах?

Question

На обычных 64-битных архитектурах, таких как x86-64 и arm64, обычно только 48 бит используются для адресации памяти, тогда как другие биты являются копиями бита 47 (который обычно равен нулю для программ пользовательского пространства). Таким образом, оставшиеся 16 битов могут использоваться для хранения дополнительных данных, таких как теги типа и т. Д., При условии, что эти биты маскируются перед разыменованием. В качестве альтернативы, 48 бит могут вписываться в NaN-представление 64-битного числа с плавающей запятой. Обе технологии часто используются в динамических / интерпретируемых языках.

Я читал о 5-уровневом пейджинге Intel, который расширил бы диапазон адресов с 48 до 57 бит, таким образом, значительно уменьшив оставшиеся биты, а также отобразив NaN. Бокс невозможен. Ядро Linux уже добавило поддержку этой схемы пейджинга.

Учитывая, что 48 бит соответствуют 262 144 ГБ памяти, мы можем предположить, что 57-битный диапазон нам не понадобится в ближайшее время на потребительских устройствах, таких как ПК, ноутбуки. и телефоны, и, таким образом, можно предположить, что на этих устройствах мы будем оставаться в 48-битном режиме в течение долгого времени, при этом вышеупомянутые методы остаются жизнеспособными, в то время как 57-битный режим будет использоваться только для серверов / суперкомпьютеров.

Правильно ли я делаю эти предположения? Или есть признаки того, что даже устройства потребительского масштаба будут использовать 57-битный режим в ближайшем будущем?

Answer 1

Даже если постоянное хранилище с отображением в памяти становится широко распространенным (NV-DIMM), пройдет некоторое время, прежде чем потребительские ПК получат более 64 ТБ или 128 ТБ памяти + DRAM. Помните, что ядра с высокой половиной требуют половину виртуального адресного пространства для использования ядром и обычно хотят напрямую сопоставить всю физическую память с немного непрерывным диапазоном виртуальных адресов. Как и , как и другие отображения в пространстве ядра, я думаю. например, см. https://www.kernel.org/doc/Documentation/x86/x86_64/mm.txt о том, что делает Linux.

Как вы подозреваете, операционные системы на самом деле не будут включать PML5 на компьютерах, которые имеют физическое адресное пространство намного меньше 256 ТБ. Нет необходимости в таком большом виртуальном адресном пространстве, и это снижает производительность (более дорогие обходы страниц с таблицами страниц другого уровня). Аппаратные средства просмотра страниц не всегда могут сохранять в кэше две фактически используемые записи верхнего уровня;Недействительность всего на изменениях CR3 может вызвать сброс. (Оборудование для обхода страниц может, как правило, кэшировать верхние уровни дерева радиуса, чтобы ускорить пропуск TLB для соседних страниц.)