Linux 7.4: RISC-V получил переносимую оптимизацию производительности

В ядро Linux 7.4 слит набор изменений для RISC-V, среди которых выделяется оптимизация копирования данных между пользовательским пространством и ядром. Главное отличие от прошлого цикла — определение быстрого доступа к не выровненным данным теперь выполняется во время работы системы, а не при сборке.

Оптимизация, которая в Linux 7.3 работала только для узкоспециализированных сборок ядра, в версии 7.4 стала переносимой — и теперь её смогут получить пользователи обычных дистрибутивных ядер для RISC-V.

Что случилось

В основную ветку Linux 7.4 слит пул изменений архитектуры RISC-V. Список нововведений там довольно содержательный, но наибольший интерес представляет доработка, которая ускоряет копирование данных между пользовательским пространством и ядром на процессорах с быстрым доступом к не выровненным адресам памяти.

Суть в следующем. Когда ядро копирует данные из пользовательского пространства (или обратно), оно исторически подстраховывается: если адрес не выровнен по границе слова, часть реализаций RISC-V работает с такими обращениями медленно или вовсе не поддерживает их аппаратно. Поэтому в горячих путях копирования добавляется программное выравнивание — данные аккуратно дочитываются по краям, а середина копируется уже выровненными блоками. Это корректно, но стоит дополнительных инструкций.

Если же конкретный процессор умеет обращаться к не выровненным данным столь же быстро, что и к выровненным, всё это программное выравнивание — чистый накладной расход. Идея оптимизации — распознать такой процессор и пропускать лишнюю работу.

История вопроса: от 7.3 к 7.4

Впервые эта идея появилась в Linux 7.3: её внедрили инженеры Tenstorrent, компании, известной своими RISC-V-процессорами. Тогда флаг HAVE_EFFICIENT_UNALIGNED_ACCESS задавался на этапе компиляции. То есть ускорение включалось, только если ядро изначально собиралось под конкретное железо с поддержкой быстрых не выровненных обращений.

В собственных тестах Tenstorrent такая доработка давала прирост пропускной способности до 11%. Важная оговорка: цифра получена силами вендора на его сценариях, и независимого подтверждения этого конкретного значения публично нет. Тем не менее сама логика понятна: в путях, где копируются большие объёмы данных, избавление от лишних проверок на границах блоков заметно.

Проблема была в переносимости. Дистрибутивы собирают одно ядро на широкий круг машин, причём в пределах архитектуры RISC-V встречается самое разное железо — от дешёвых микроконтроллерных SoC до серверных чипов. Если включить оптимизацию на этапе компиляции, есть риск, что ядро попадёт на процессор, который с не выровненными обращениями справляется плохо, — и вместо ускорения пользователь получит регресс или даже некорректную работу. Поэтому дистрибутивы не могли безопасно включать эту опцию в универсальных сборках.

В Linux 7.4 проверка перенесена на время выполнения. Теперь ядро при старте определяет, поддерживает ли процессор эффективный доступ к не выровненным данным, и только после этого решает, пропускать ли программное выравнивание в путях копирования из пользовательского пространства. Одна сборка ядра работает корректно везде, а ускорение получают те машины, где оно действительно применимо.

Именно это делает оптимизацию практически значимой: она переходит из разряда «экзотики для специализированных сборок» в функцию, которую смогут включить обычные дистрибутивные ядра Debian, Fedora, Ubuntu и других проектов с RISC-V-сборками.

Что ещё вошло в пул RISC-V для Linux 7.4

Помимо главной оптимизации, в архитектурный пул добавлено ещё несколько изменений:

• поддержка crash hot-plug — обработки горячего подключения оборудования в режиме аварийного дампа;
• оптимизированные пути выполнения для ряда функций работы с таблицами страниц;
• ускорение при переключении контекста — одна из самых частых операций в многозадачной системе;
• расширение инструкций «B» (битовые операции) добавлено в отчёты через интерфейсы hwcap и hwprobe, что позволяет приложениям узнавать о доступных возможностях процессора;
• появилась поддержка отчёта о расширении Zic64b.

Отдельно стоит упомянуть hwprobe: это механизм, через который пользовательские программы могут спросить у ядра, какие именно RISC-V-расширения доступны на данной машине. Расширение набора отчётности — скромная, но полезная вещь: компиляторы и высокопроизводительные библиотеки используют такие данные, чтобы выбрать оптимальный код под конкретный чип.

Почему это важно на практике

RISC-V переживает стадию, когда производительность решают мелочи. Архитектура открыта, базовые инструкции стандартизированы, но конкретные реализации очень разнятся: есть чипы с медленной памятью и слабыми конвейерами, а есть серверные решения, где каждый процент пропускной способности на счету.

Для пользователей это означает простое: на тех RISC-V-системах, где процессор хорошо работает с не выровненными обращениями, операции ввода-вывода и системные вызовы, связанные с передачей данных между приложением и ядром, должны стать чуть быстрее. Прирост будет неравномерным и зависеть от рабочей нагрузки — сильнее всего в задачах с интенсивным обменом данными, слабее в вычислительных сценариях. И здесь стоит сохранять осторожность: единственная оцифрованная величина прироста — те самые «до 11%» в тестах Tenstorrent, и переносить её на произвольное железо нельзя.

Есть и инженерный аспект. Перенос проверки во время выполнения — правильное архитектурное решение для архитектуры с большим разбросом реализаций. RISC-V не контролирует «железную базу» так, как это делают x86 или Arm, где вариативность ниже, и универсальные ядра неизбежно должны уметь адаптироваться. Каждое такое изменение повышает шансы RISC-V стать полноценной платформой для серверов и настольных систем, а не только для встраиваемых устройств.

Чего ждать дальше

Пул RISC-V для Linux 7.4 уже слит в дерево основного разработчика, так что изменения попадут в стабильный релиз 7.4 по обычному графику. Реальные замеры производительности появятся, когда дистрибутивы начнут тестировать новые ядра на доступном RISC-V-железе — тогда станет понятно, насколько заметен эффект за пределами тестовых стендов Tenstorrent.

В целом пул выглядит аккуратной инженерной работой: без громких заявок, но с изменениями, которые устраняют реальные барьеры для распространения ускорений. Для экосистемы, где главная проблема — разнородность железа, превращение «оптимизации для своей сборки» в «оптимизацию для всех» ценнее, чем сам по себе процент производительности.