- 1
- 2
- 3
https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf
http://lkml.iu.edu/hypermail/linux/kernel/1612.1/00383.html-
Куча / Говнокод #23651
−1
x86-64 is currently limited to 256 TiB of virtual address space and 64 TiB
of physical address space. We are already bumping into this limit: some
vendors offers servers with 64 TiB of memory today.
To overcome the limitation upcoming hardware will introduce support for
5-level paging. It is a straight-forward extension of the current page
table structure adding one more layer of translation.
It bumps the limits to 128 PiB of virtual address space and 4 PiB of physical address space.
This "ought to be enough for anybody" Â.
https://imgs.xkcd.com/comics/supported_features.pngЗапостил:
3.14159265,
11 Января 2018
Follow us!
Ну да. Пару лет назад на ГК уже предлагал такую идею.
Использовать 32ю-битную адресацию в x64.
Вот прям сейчас на моём десктопе ни одному из работающих процессов не нужно более 4х гиг памяти.
Если даже в 2к18 хватает 32 бит на процесс, зачем тогда использовать 64-битные указатели адреса?
В любом случае все адреса уже лет 30 как виртуальные, и не соотвествуют физическим.
За эти годы намазали столько абстракций что пришлось пилить TLB для ускорения вычисления реальных адресов.
Можно уменьшить все массивы с указателями, все таблицы виртуальных функций, более плотно забивать кеши.
При том я предлагал сиё еще до всяких meltdownов. Если каждый процесс заточён в матрице 4гиг своей виртуальной памяти, как он в принципе может смотреть в память чужого процесса?
Любое переполнение 32-битного адреса простоприведёт к враппингу и не приведёт к плачевным итогам. Но нет, нужно выдумывать запредельно сложные костыли и прочую ASLR-питушню.
В моей практике даже на серверах процессы занимающие более 4х гиг были довольно редки. И обычно мы с таким боролись.
Поскольку на таких больших кучах, становились болезненными существенные задержки от stop-the-world.
П.С.: 32-разрядные оси тоже уязвимы, на сколько я понимаю.
Хм, даже Дональд Кнут соглсен с моей точкой зрения.
A Flame About 64-bit Pointers
It is absolutely idiotic to have 64-bit pointers when I compile a program that uses less than 4 gigabytes of RAM. When such pointer values appear inside a struct, they not only waste half the memory, they effectively throw away half of the cache.
The gcc manpage advertises an option "-mlong32" that sounds like what I want. Namely, I think it would compile code for my x86-64 architecture, taking advantage of the extra registers etc., but it would also know that my program is going to live inside a 32-bit virtual address space.
Unfortunately, the -mlong32 option was introduced only for MIPS computers, years ago. Nobody has yet adopted such conventions for today's most popular architecture. Probably that happens because programs compiled with this convention will need to be loaded with a special version of libc.
Да знаю, но оно ж ABI, там надо всё пересобирать/перелинковывать.
И еще там есть неприятный нюанс: ассемблерные вставки могут сломаться и ломаются.
А без них...
Короче потому и не взлетел, что надо софт портировать и вдовесок к lib и lib64 тащить libx32
Вот как например реализованы те же transparent huge pages? Мы не посылаем нахуй тех кому нужны страницы по 2 и 4 Мб, но при этом поддерживаем странички по 4Kb.
А вот обратное... скажем, мне понадобилась 64-битная программа (да тот же бинарь Qt под Linux) - так пришлось систему переставлять. Может, пусть луше будет 64-битное единообразие?
Это повод для гордости?
Это факт. Маппинг файлов в виртуальную память — очень полезная техника, у которой практически нет алтернатив. Алсо,
Я говорю что большинству программ до сих пор хватает 32-разрядных адресов. Зачем нужны 64 указатели - большой вопрос.
>yandex/mms
Да это всё узкая серверная питушня и ЯНДЕКСОПРОБЛЕМЫ, думаю найдётся тот кто скажет что ему мало и петабайта виртуальной памяти:
> x86-64 is currently limited to 256 TiB
Такое ощущая хачий обратно, выдетъ странице етой индекс
ёe сжимаем этим "Ctrl"