Одной из проблем и в то же время достоинств Linux является поддержка многих старых архитектур процессоров. Это увеличивает размеры ядра и усложняет сопровождение. Но теперь, похоже, на одну архитектуру станет меньше. В ядре Linux 5.11, как выяснилось, оказалась нарушена поддержка Itanium IA-64.

После исправления выяснилось, что это не единственная проблема такого рода, однако истинную причину выяснить не удалось из-за отсутствия доступа к «железу». Так что Линус Торвальдс (Linus Torvalds) в итоге принял решение пометить данную архитектуру как orphaned, то есть заброшенную, и прямо заявил, что она мертва. А это первый шаг к полному исключению её из ядра, как это уже случилось с другим продуктом Intel — Xeon Phi.

Изображения: wikipedia.org

Два последних крупных игрока на рынке Itanium-систем — сама Intel и её клиент HPE — уже давно забросили поддержку этой архитектуры в Linux, да и энтузиасты к ней охладели. И это объяснимо. Последнее поколение Itanium 9700 Kittson вышло в 2017 году, а приём заказов на них прекратился год назад. Поставки формально будут свёрнуты 29 июля 2021 года, но эти CPU с высокой степенью вероятности практически никто не закупил хоть в сколько-то значимых объёмах.

Несбывшиеся надежды

В дистрибутивах же поддержку процессоров убрали давно. Red Hat не поддерживает чипы с RHEL 5, SUSE перестала поддерживать после SUSE Linux 11. Так что теперь поддержка будет осуществляться лишь теми компаниями, которые явно заинтересованы в этом. Разумеется, если такие остались. В своё время спор между Oracle и HPE подорвал репутацию платформы. Впрочем, Linux не является единственным вариантом — поддержка HP-UX, наследника классических UNIX, версии 11i v3 для ряда продуктов HPE будет осуществляться до 31 декабря 2025.

Аналогичная ситуация сложилась и вокруг SPARC c Solaris, так как большую часть разработчиков обоих продуктов Oracle уволила ещё в 2017 году. Oracle обязалась сопровождать Solaris 11 максимум до 2034 года. В частности, на днях она выпустила патч безопасности для sudo и восстановила некоторые старые материалы. Однако Solaris 12 мы вряд ли когда-либо увидим. Сейчас компании гораздо более интересны облака, Linux и Arm-процессоры Ampere.

Дата релиза Debian 11 (Bullseye) пока не сообщается разработчиками. Однако они уже готовятся к началу работы над Debian 12. И, судя по первым сведениям, в этой сборке могут сократить поддержку процессоров i386. Для версии 11 мягкая заморозка кодовой базы стартует 12 февраля, а полная — месяцем позже. Для Debian 11 будут поддерживаться архитектуры AMD64, ARM64, ARMEL, ARMHF, i386, MIPS64EL, MIPSEL, PPC64EL и s390x. Таким образом, сейчас отказались только от базовой версии MIPS.

theregister.com

Между тем, в Debian 12 (Bookworm) число «отказников» может вырасти. В последнее время ведутся дискуссии о состоянии поддержки архитектуры i386 и о том, как с этим справиться в будущем. Пока что основном мнением является продолжение поддержки 32-битных процессоров. Однако окончательное решение пока не принято.

Отметим, что Debian 11 «Bullseye» должен быть выпущен в этом году, тогда как Debian 12 «Bookworm» появится не раньше 2023 года. Потому не исключено, что к тому времени вопрос поддержки означает будет не слишком актуален. Также отметим, что уже известно кодовое наименование дистрибутива Debian 13 — «Trixie». Его релиз ожидается примерно в 2025 году.

Ядро Linux 5.10 стало очередным релизом с долгосрочной поддержкой (LTS), который будет поддерживаться как минимум в течение следующих пяти лет. И потому в сообществе началось обсуждение отказа от поддержки ряда устаревших процессоров и архитектур. В числе аргументов сторонники удаления отмечали, что многие платформы не получали обновлений и коммитов уже много лет.

Разработчик Арнд Бергманн (Arnd Bergmann) предложил список из 30 с лишним платформ Arm, которые можно было бы безболезненно убрать. Большая часть из них, попав в основную ветку ядра, получала обновления в течение 1-3 лет, после чего была заброшена. Другая часть относится к «доисторическим», то есть к таким, которые уже давным-давно не производятся.

hackster.io

Наконец, есть перечень платформ, которые давно «мертвы» и не поддерживаются разработчиками порядка 10 лет:

• H8300
• C6X
• SPARC/Sun4M
• PowerPC: CELL (не считая PS3), CHRP, AmigaOne, Maple
• M68K: Apollo, HP300, Sun3, Q40
• MIPS JAZZ и Cobalt

Кроме того, есть и архитектуры, которые тоже можно рассмотреть в качестве кандидатов на исключения из ядра Linux:

• 80486SX/DX — поддержка 80386 прекратилась в 2012 году, нет смысла поддерживать и 80486.
• Alpha 2106x — системами на базе любых Alpha вряд ли кто-то пользуется.
• IA64 Merced — первое поколение Itanium, на смену которым через год пришли Itanium II.
• MIPS R3000/TX39xx: 32-бит чипы MIPS-II (не путать с более современной MIPS32), которые с 1991 года вытеснены 64-бит MIPS-III.
• SuperH SH-2 — популярная в середине 90-х архитектура для встраиваемых систем.
• 68328 (DragonBall) — поддержка похожих микроконтроллеров 68360 удалена в 2016 году. Поддержка более новых 68020+ и Coldfire MCF5xxx сохранится.

Вопрос об удалении старых архитектур возник не на пустом месте. Арнд Бергманн изучал текущее состояние 32-бит платформ и потенциальную возможность отказа от них, так как полный переход на поддержку только 64-бит архитектур значительно облегчил бы жизнь разработчиков во многих аспектах. Ранее он предположил, что через десять лет среди массовых архитектур останутся только x86-64, ARM и RISC-V.

Современные объёмы жёстких дисков и технологии RAID уже давно позволяют собирать системы на десятки Тбайт данных. Однако не всегда есть возможность задействовать такие объёмы из-за ограничения аппаратной и программной частей. В строю до сих пор есть масса устаревших NAS на базе 32-битных процессоров ARM и не самых свежих ядер Linux.

Однако в такой конфигурации есть проблема, связанная с тем, что по умолчанию используются 4-КиБ (кибибайт) физические страницы, а это накладывает ограничение на максимальный размер адресуемой памяти в 16 ТиБ (~17,59 Тбайт) для хранилища, причём это практически не зависит от файловой системы. Проще говоря, современные накопители, которые уже достигли 20-Тбайт объёма, подобный NAS попросту не «осилит».

kobol.io

Одно из решений проблемы — использование страниц памяти большего размера. Точнее говоря, их эмуляция, так как есть некоторые нюансы в организации работы с памятью внутри ядра и собственно аппаратной реализацией в 32-бит ARM. Другим подходом является использование 64-битных (pgoff_t) смещений для адресации файловых систем, и некоторые производители уже используют его.

Подробнее обо всём этом компания Bootlin рассказывает в своем блоге. Именно она по заказу неназванного производителя NAS подготовила серию патчей для решения этой проблемы. Причём её реализация поддерживает страницы размером 4, 8, 16, 32 и 64 КиБ. То есть это даёт возможность работы с 256-ТиБ пространством в случае 64-КиБ страницы.

Патчи были выпущены довольно давно, но до сих пор не добавлены в основную ветку ядра Linux. И вряд ли будут. Одной из причин этого является тот факт, что поддержка больших страниц для 32-битной ARM-системы увеличивает расход памяти. Так что компромиссным вариантом пока является использование 8-КиБ страницы, которые дают поддержку до 32 ТиБ при минимально возможном перерасходе памяти.

Набор SIMD-инструкций Intel MMX, представленный в 1997 году, является откровенно устаревшим и уже давно вытеснен различными версиями SSE и AVX. Тем не менее, в средствах разработки они всё ещё формально поддерживаются. Правда, в силу редкости использования, их имплементация страдает от багов. Поэтому неудивительно, что их в очередной раз предложили выкинуть из популярного набора компиляторов LLVM.

В обсуждении, начатом в листах рассылки, предлагается переписать и заменить интринсики для MMX на новые, использующие уже имеющиеся для SSE или, лучше, SSE2. Текущие требуют некоторый внимательности от разработчика, так как при некорректном использовании программа будет не падать, а выдавать некорректные результаты. В дальнейшем предлагается исключить MMX из представления LLVM IR.

Единственный способ использования этих инструкций и сопутствующих регистров, если это по какой-то причине действительно нужно — использование ассемблерных вставок непосредственно в коде. Любопытно, что, судя по всему, даже физически отдельных регистров для x87/MMX в современных процессорах уже нет — они делят «кремний» с регистрами для маскирования AVX-512, так как вероятность высокой нагрузки со стороны обоих типов инструкций одновременно крайне маловероятна.

Отказ от MMX, естественно, повысит минимальные требования LLVM. Однако сейчас трудно найти работающую x86-систему, в которой нет поддержки SSE2 или хотя бы SSE. Это перекликается с активизировавшимися призывами отказаться от поддержки старых CPU вообще, 32-битных и без современных инструкций. В частности, Fedora и RHEL уже движутся в этом направлении.