Из ядра 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) ну и наконец, либо внутри приложения придётся делать ещё один менеджер памяти и менеджер многозадачности, чтобы выделять этот свап правильно, либо работать это всё будет с заметными тормозами

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

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

Еще точнее - это просто способ адресации, напоминающий таковой способ (сегмент+смещение) в 8086/88 и в реальном режиме последущих процессоров.

Появился действительно впервые в Pentium Pro. В некоторых системах адресация, несмотря на PAE, нарочно ограничена 4 Гб. В WinXP (32-битной) самый известный случай. Там можно включить PAE, но более 4 Гб система не увидит. Слегка пропатчив можно и на WinXP добиться работы с полным объемом памяти.

Нет, на сегменты это не похоже, практически ни с какой стороны. Ни по реализации, ни по идеологии, ни по сфере применения.

Очень важная инфа, держи в курсе

Это реально чушь, PAE был востребован когда куча софта была 32-х битной и пользоваться 64-х битным linux было не вариант. Например какой-нибудь Oracle XE под linux был только 32-х и прочие подобные проприетарные поделки, а тебе нужно еще с этим работать, писать код и т.д, вот и получалось что требовалось много памяти. Но обычным пользователям PAE был не нужен, показателем этого является хотя бы то что PAE не было на винде.

Нет, на сегменты это не похоже, практически ни с какой стороны. Ни по реализации, ни по идеологии, ни по сфере применения.

Спор схоластический какой-то. На прикладном уровне конечно не похоже, там как была, так и осталась 32-битная линейная адресация в пределах 4 Гб адресного пространства. На физическом так и остаются селекторы и сегменты для организации виртуального адресного пространства. Но с дополнениями в случае PAE.

Между прочим, интересно, было ли такое, чтобы какая-нибудь ОС предоставляла API для 32-битных программ для работы с более, чем 4 Гб? По типу как EMS-память во времена DOS. А может все могут, но я не в курсе :))

Ща погуглил. Было конечно, например, AWE - https://ru.wikipedia.org/wiki/Address_Windowing_Extensions никогда не применял. Но видимо в энтерпрайзе использовалось.

Какие новости по Гайке? Когда КДЕ портируют? :) Что там с дровами? Подписан в Матриксе на вашу тусовочку, но давно не читал. Рассказывай :)

Но обычным пользователям PAE был не нужен, показателем этого является хотя бы то что PAE не было на винде.

Как это не было на винде? Было как минимум, начиная с Windows 2000. Насчет NT 4 не уверен, в принципе в позднейших сервиспаках могли и туда добавить.

Другое дело, что в WinXP по умолчанию PAE выключен, а если включить, то ограничен 4 Гб без патча, убирающего это ограничение.

Насчет нужности вопрос спорный. Большинству обычных пользователей до конца нулевых больше 4 Гб не особо нужно было конечно. Более того, сильно далеко не каждая материнка в эпоху до Athlon64 и CoreDuo вообще поддерживала объем выше 4 Гб.

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

Но на 64 бита не переходишь?

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

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

На физическом так и остаются селекторы и сегменты для организации виртуального адресного пространства. Но с дополнениями в случае PAE.

Опять нет. Селекторы и сегменты уже в линейном адресном пространстве (том, которое 4гб). И про PAE они ничего не знают, т.к. оно работает вне этой абстракции.

Это железо, оно сейчас в одной комнате с нами?

планируемое устаревание

Ало, оно уже само устарело морально и технически, сколько этомуу железу, по 20 лет уже?
Ну и снова к устареванию. Ядра lts 5.10-6.12 поддерживаются до декабря 26 года, возможно, что ещё и продлят.

Ало, оно уже само устарело морально и технически

Это и есть планируемое устаревание. Новый софт делают с завышенными системными требованиями без реальной на то надобности.

Ядро не отказывается от поддержки 32-разрядных процессов на 64-разрядном ядре. Для любителей 32-разрядного юзерспейса на 64-разрядном процессоре этого достаточно. Это и работает хорошо, и юзерспейсу даёт все 4 гб адресного пространства.

Так ли много осталось систем с 32-разрядными процессорами и памятью больше 4 гб? Таких систем изначально было мало. Ведь это было во времена 2000-2006, когда контроллер памяти был в чипсете. А чипсетов с поддержкой памяти более 4 гб за всю историю было меньше, чем пальцев на руке.

загружает в память 6гиговый G-код

А как в 32 битах обратится к 6 гб?

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

Даже с PAE у тебя каждый процесс лимитирован 4GB пространством адресации. PAE нужен только когда много процессов которые совокупно занимают больше 4-х GB.

Ну два файла по 3 гига.

Да, но в моей вымышленной железке допустим есть некий аппаратный транслятор, который позволяет делать выборку не по индексу, а по итерации запроса, а внутри будет просто прыг указателя, обнуление внутреннего счётчика, и вот новый указатель по смещению с свежий счётчик можно щёлкать дальше =) Я конечно выдумываю, но, я и первую железку печатающую из металла коня выдумал. Ну или просто как морковке ответил, два файла по 3 гига, загружаются в память и аппарат начинает автономно работать, например требование такое, придти в независимое от сети состояние и начать работу, иначе не начинать.

Да я фантазёр. Но сейчас такое время что любую хреныь выдумай она либо была, либо есть, либо будет завтра.

G-код обычно вообще построчно читается из файла и похрен сколько он там на диске (или его эквиваленте) занимает.

С PAE другое непонятно - это в общем-то просто отдельный вариант MMU в x86 - ну всякие TLB и реализации phys_to_virt/virt_to_phys и пр. другие, и этот кусок кода никуда больше не отсвечивает и ничему не мешает, потому что всё остальное использует phys_to_virt/virt_to_phys при необходимости. Т.е. оно никакому развитию остального кода мешать не может, как не мешают всякие разные MMU разных других архитектур. Менять там нечего, да оно и не менялось уже х.з. сколько. Лежит и лежит, жрать не просит.

Если только решили в ядре зачем-то перепилить самую мякотку - работу с MMU. А вот это уже тревожный звоночек и ничего хорошего не предвещает.