Падение производительности AMD-видеокарт до 42 раз ждёт пользователей Ubuntu 26.04 и владельцев HWE-ядра в Ubuntu 24.04 после перехода на сборку 7.0.0-28.28. Команда ядра Ubuntu опубликовала предупреждение , до того как обновление разойдётся по репозиториям. Регрессия проявляется на вычислительных нагрузках через ROCm: генерация изображения в ComfyUI по модели Stable Diffusion XL растягивается с 9 до 388 секунд. Речь идёт о падении пропускной способности, а не о зависании системы. Причину нашли и устранили ещё в ядре 7.0.13, но в Ubuntu исправление попадёт только со следующим обновлением ядра.
Замедление SDXL с 9 до 388 секунд
Цифра в 42 раза взята из отчёта в трекере ROCm, открытого . В нём описан переход на Fedora 44 с ядра 7.0.11-200 на 7.0.12-200: время генерации по модели SDXL в ComfyUI выросло с 9,14 до 388,25 секунды. Конфигурация системы: Radeon RX 6950 XT (gfx1030), ROCm 7.1.1-4, PyTorch 2.12.0+rocm7.2, ComfyUI 0.24.0. На модели SD1.5 разница осталась в пределах погрешности — 4,47 против 4,73 секунды.
ROCm — открытая программная платформа AMD для вычислений на видеокартах: драйверы, компиляторы, отладчики и библиотеки, поверх которых работают PyTorch и TensorFlow.
Скорость итераций при генерации на обоих ядрах одинакова, около 5 итераций в секунду. Отсюда вывод в отчёте: замедление возникает не в самом расчёте на видеокарте, а на этапе до старта генерации. В журнале dmesg ошибок нет ни на одном из ядер. Откат на 7.0.11-200 сразу возвращает нормальные показатели, а на 7.0.12-201 регрессия воспроизводится так же.
Кого затрагивает переход на ядро 7.0
Основная группа риска — Ubuntu 26.04. Вторая — пользователи Ubuntu 24.04 со стеком HWE, которых по графику переводят с ядра 6.17 на 7.0. Границы проблемы в команде ядра Ubuntu пока уточняют; подтверждённые сообщения приходят с систем на AMDGPU, где задействован ROCm, и касаются вычислительно тяжёлых сценариев вроде SDXL.
HWE (Hardware Enablement Stack) — механизм Ubuntu, который приносит в LTS-выпуск более новое ядро и графический стек из свежих промежуточных релизов. На настольных установках 24.04 он включён по умолчанию, на серверных предлагается опционально.
Цикл повтора в amdgpu_hmm_range_get_pages
Регрессия пришла в 7.0.12 вместе с коммитом c08972f55594 (drm/amdgpu: fix amdgpu_hmm_range_get_pages), который вынес вызов mmu_interval_read_begin() за пределы цикла обработки блоков. Сохранённое значение notifier_seq после этого перестало обновляться между попытками.
Функция hmm_range_fault() отдаёт -EBUSY только тогда, когда mmu_interval_check_retry() сообщает об устаревшей последовательности. Как только последовательность сдвинулась, сохранённое значение уже никогда не совпадёт, и каждый следующий вызов внутри той же операции возвращает -EBUSY сразу.
HMM (Heterogeneous Memory Management) — подсистема ядра Linux, которая даёт устройству вроде видеокарты доступ к адресному пространству процесса: таблицы страниц процессора зеркалируются на стороне устройства и синхронизируются при изменениях.
Переход по метке retry в результате вырождается в холостое ожидание: процессор впустую крутится весь отведённый интервал HMM_RANGE_DEFAULT_TIMEOUT (около секунды), после чего операция всё равно завершается с -EAGAIN. Тяжелее всего это сказывается на стеке userptr в KFD — вызывающий код на секунду блокируется, удерживая mmap_lock, и возвращает -EAGAIN восстанавливающему обработчику, который тут же повторил бы операцию сам.
Исправление — коммит dd03cee в файле amdgpu_hmm.c — убирает цикл повтора и таймаут целиком: -EBUSY уходит прямо в out_free_pfns, где и без того превращается в -EAGAIN. Восстановление берёт на себя более высокий уровень: обработчик restore_userptr_worker в KFD перепланирует себя, а ioctl-путь userptr отдаёт -EAGAIN в пространство пользователя. Удалено восемь строк, добавлена одна. Ядро 7.0.13 с этой правкой вышло .
Сообщения о проблеме в Fedora 44 и CachyOS
Второй отчёт, от , пришёл в трекер ComfyUI от пользователя CachyOS. На ядре 7.0.12 загрузка модели SDXL занимала до десяти минут вместо примерно тридцати секунд, а повторные попытки генерации срывались. Проблема воспроизвелась на Radeon RX 9070 XT, ещё один участник обсуждения подтвердил её на RX 7900 XTX. Откат на 7.0.11 вернул нормальную работу.
Почему 7.0.0-28.28 выйдет с регрессией
В команде ядра Ubuntu решение объяснили приоритетом критических исправлений безопасности, которые входят в тот же выпуск. Регрессия в 7.0.0-28.28 останется, зато обновление с патчами безопасности не задержится. Правку поставили в очередь на ближайшую следующую партию обновлений с критическими исправлениями.
Заключение
Пользователям Ubuntu 26.04 и стека HWE в 24.04, которые считают на AMD через ROCm, рекомендовано остаться на текущем ядре и пропустить 7.0.0-28.28 до выхода следующего обновления. Подтверждённые сообщения пока ограничены вычислительными нагрузками, но границы проблемы уточняются. Расхождение графиков видно наглядно: в основной ветке ядра исправление доступно с , а в стабильную ветку Ubuntu попадёт только выпуском после 7.0.0-28.28.