Из ядра Linux уберут поддержку (PAE) HIGHMEM64G?

Интересно, кому-нибудь сейчас нужно PAE?

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

А так, в потребительском секторе, массовом, не знаю. Уверен что применения есть, но не настолько на данный момент широкие. Вот и выпиливают.

Интересно, кому-нибудь сейчас нужно PAE?

Очевидно, тем у кого больше 4ГБ памяти. У меня например 8ГБ.

Не знаю зачем они решили его дропнуть, очередное идиотское решение.

Попытался по ссылке прочесть мотивацию - там одна вода и бред.

загадка почему мы пришли сейчас к тому, что 32-бинтые x86 НЕ по умолчанию с PAE

Странное решение. В Haiku код поддержки PAE никому не мешает. В *BSD полагаю тоже.

Может им сразу убрать поддержку 32 битных x86, к чему какие-то полумеры?

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

И оно прям регулярно обновляется на последнее ядро? :)

Если где-то такое есть, там может еще Линукс 2.x.

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

Какой-то очень интересный станок с 64-битным процессором и памятью за 8 гектар, на котором надо загрузить 32-битный линух.

Интересно, кому-нибудь сейчас нужно PAE?

Ну само PAE же не убирают, потому что оно нужно для всяких NX-bit. Убирают HIGHMEM64G.

Очевидно, тем у кого больше 4ГБ памяти

Им, очевидно, нужен x86_64, а не убогий костыль в виде PAE.

кому-нибудь сейчас нужно PAE

Linux debian 6.10.12-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.10.12-1 (2024-10-01) i686 GNU/Linux

и на этом все затихло - с прошлого года обновлений нет

очень интересный станок с 64-битным процессором

процессор может быть и не 64-битный

Ну бред же.

ЗЫ Пора делать форк.

Я правильно понимаю что одной рукой выпиливают рейзер и пае, а другой тащат раст?

Не думаю, что этот станок крутится на блединг-эдж версиях ванильных ядер. Там небось до сих пор какой-нибудь потато.

В FreeBSD кстати мешает. То есть оно там есть в опциях компиляции, но по умолчанию выключено, а когда я его захотел включить (давно было), обнаружил где-то надписи о том что оно не рекомендуется. Сейчас уже не помню где они именно были, но в мане тоже не очень хорошая картина: https://man.freebsd.org/cgi/man.cgi?query=pae&sektion=4 (секция BUGS).

PAE это и есть доступ к >4G. NX-бит туда засунули просто заодно.

Не надо говорить за других. Мне не нужно 64, у меня 32-битное ядро.

И PAE - не костыль.

Не надо говорить за других. Мне не нужно 64, у меня 32-битное ядро.

А если не секрет, а зачем тебе новое ядро и столько памяти на 32-битном железе?

И PAE - не костыль

Прости, но я мнению Торвалдса в этом плане больше доверяю, чем упоротому, у кого

не нужно 64, у меня 32-битное ядро

А если не секрет, а зачем тебе новое ядро и столько памяти на 32-битном железе?

Всё не так.

1) новое ядро мне не нужно, стоит debian 11 и в нём ядро 5.10, но когда-то и 6.14 станет старым

2) железо 64-битное

А памяти много затем чтобы она не кончалась.

Выкинут и выкинут, че бухтеть то.
Логика простая - это все не нужно, а 64-битному оборудованию соответствующее ядро x86-64. А про все те переходные периоды забыть и выбросить.
Ну, какая-то логика в этом есть.

Пока отчекрыжат всё лишнее, а там будут смотреть.
Вообще, есть ли новое\актуальное железо x86, которое не 64битное? Оно вообще есть?
Думаю, что в скором времени x86-32 оставят только для гостевых vm.

поставь 64-битное ядро уже.

Странный какой-то конфиг, 12й дебиан вполне стабильный, если требуется какое-то ооочень специфичное 32-битное ПО - ну добавь i386 архитектуру и замути чрут или контейнер с 11-м дебианом. В чём смысл так страдать? И да, вполне резонный недоумённый вопрос - а как тебя затрагивает выпил PAE в новых ядрах, если у тебя 5-я ветка?

Вообще, есть ли новое\актуальное железо x86, которое не 64битное?

Есть огромное количество рабочего 32 битного железа с PAE. Зачем топить за планируемое устаревание?

12й дебиан вполне стабильный

11й тоже стабильный, а тратить время на обновление я пока что не хочу. Будет лишнее время - посмотрю. Просто apt-get dist-upgrade мне практически гарантированно что-то сломает т.к. система кастомная.

если требуется какое-то ооочень специфичное 32-битное ПО - ну добавь i386 архитектуру и замути чрут или контейнер с 11-м дебианом.

Я лучше просто не буду чинить то что не сломалось.

В чём смысл так страдать?

Кто страдает?

И да, вполне резонный недоумённый вопрос - а как тебя затрагивает выпил PAE в новых ядрах, если у тебя 5-я ветка?

Сейчас - никак не затрагивает. Я отвечал на вопрос «кому нужно PAE?». Но в далёком будущем, когда я буду рассматривать обновление до debian 13, это вероятно будет дополнительной проблемой. Поскольку смена 32->64 требует намного больше времени чем апгрейд, вероятно я это делать не буду вообще. Возможно, проще тогда уже со сменой базы на фрибсд будет это совместить.

если мне не изменяет память, это про юзание дополнительных 4 бит в 32битном адресном пространстве. ошибаюсь?

помню оракл настраивал где-то лет 20+ назад, чтобы он будучи 32битным мог юзать больше памяти. в линухе юзерспейсный объем для адресного пространства 3Гб из 4. и с помощью этой фичи (при наличии бОльшего объема физпамяти) оракл мог юзать и ее, не ограничиваясь 3мя гб.

А памяти много
У меня например 8ГБ.

Прекрати юморить. Тебе психиатр нужен, а не PAE.

Немного не так. Во-первых, 4 дополнительных бита были в первых процах с PAE (Pentium Pro и Pentium II), сейчас уже намного больше. Фактически, PAE это возможность использовать 64-битную таблицу страниц из 32-битного режима, и когда появились 64-битные процы - им не пришлось заново придумывать её формат, и доступная физическая память в 32+pae у них всегда такая же как и в 64-битном режиме.

А вот 2-3гб ограничение это другое - это ограничение на адресное пространство одного 32-битного процесса, и PAE никак на него не влияет. Чтобы использовать больше 2-3гб, надо сделать несколько процессов, видимо оракл так и делал (и PAE тут опять ни при чём, это можно сделать и без него и даже если на компе всего 2гб физической памяти - есть же свап).

надеюсь, что нет

оракл как раз и использовал фичу чтобы в рамках одного процесса иметь 64ГБ адресное пространство.

ЗЫ когда-то давно, 25 лет назад, изучал эту тему в ядре линукса. наваял вот такую схему даже https://imgur.com/a/25eMHtQ. это я решал задачу «отразить состояние страниц памяти процессов (в свопе или нет) через /proc»

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

Что-то мне подсказывает, что свежие ядра до этого станка доедут примерно никогда.

Повторю, PAE вообще никак не связано с адресным пространством одного процесса. Оно влияет только на возможность мапить физическую память за пределами 4гб.

Что касается «адресное пространство одного процесса 64ГБ», то это какая-то чушь. Если задействовать таблицы дескрипторов по-нормальному, то можно организовать автоматическое переключение страниц (в рамках 4ГБ) на разные части большой физической памяти. Но:

1) числу «64ГБ» там взяться неоткуда, виртуальное адресное пространство получается 2 по 32ТБ

2) чтобы сделать это в линуксе, придётся очень переделывать его менеджер памяти - в нём это совсем не предусмотрено

3) ну и наконец, либо внутри приложения придётся делать ещё один менеджер памяти и менеджер многозадачности, чтобы выделять этот свап правильно, либо работать это всё будет с заметными тормозами