Почему Meteor Lake на Linux стал медленнее: разбор регрессии производительности

Статья разбирает необычную ситуацию: двухлетние бенчмарки показывают, что Intel Core Ultra 7 155H (Meteor Lake) на Linux в конце 2025 года работает медленнее, чем в декабре 2023-го. Рассматриваются возможные причины — от изменений в ядре, компиляторе и Mesa до микрокода, ACPI и политик энергопотребления. Дается пошаговый чек-лист для диагностики регрессий, практические методы измерения (turbostat, RAPL, intel_gpu_top, perf), рекомендации по воспроизведению и минимизации проблем. В тексте сравнения с тем, как эволюционировали другие платформы, и прогнозы, чего ждать в ближайшие релизы Linux и драйверов.

Краткий контекст: что случилось с Meteor Lake на Linux

В конце 2025 года серия сравнительных тестов выявила нечастое явление: ноутбук на Intel Core Ultra 7 155H (Meteor Lake) при запуске современного стека Linux показал худшие результаты, чем те же тесты два года назад. Геометрическое среднее по более чем 200 бенчмаркам упало примерно до 93% от исходного уровня. На фоне того, что у ряда других платформ (AMD, Intel Lunar/Arrow Lake) наблюдались улучшения, это выделяется.

Почему это важно

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

Короткий перечень реалистичных причин

Изменения в ядре и политике управления энергией — например, разные параметры intel_pstate, поведение governor'ов и CPPC/ACPI.
Микрокод и BIOS/UEFI-апдейты — новые версии микрокода могут снижать рабочие частоты для соблюдения терм/пауэр-ограничений.
Драйверы графики (i915 / Mesa) — изменения в Mesa или i915 могут замедлить рендер/компьют нагрузку или ухудшить взаимодействие GPU/CPU.
Компилятор и рантаймы — GCC 15 и Python 3.13 генерируют иной код; сборка тестов под новым toolchain может быть медленнее.
Тепловой режим и троттлинг — разные прошивки, paste ageing или тепловые ограничения корпуса влияют на стабильные частоты.
Изменение дефолтных настроек дистрибутива — больше энергосбережения «по умолчанию» может снизить скорость без явной на то причины.
Регрессии в самих бенчмарках/сценариях — редкие, но возможные: зависимость теста от конкретной версии библиотек.

Разбираем причины глубже: что именно могло повлиять

1. Scheduler и гибридная архитектура

Meteor Lake — гибридная архитектура с разными типами ядер. Эффективность распределения задач между «большими» и «маленькими» ядрами зависит от модели энергопотребления и планировщика. Если ядра неправильно ранжируются по стоимости выполнения (energy model) или kernel scheduler получает некорректные данные от ACPI/firmware, нагрузка может уходить на менее подходящие ядра, что отражается в падении производительности.

2. Энергомодель и CPPC/ACPI

Современные ноутбуки полагаются на взаимодействие BIOS ↔ ACPI ↔ ядро. Обновление ядра или микрокода иногда требует скорректировать CPPC-файлы (Collaborative Processor Performance Control). Если в цепочке появляются несогласованности, система начинает агрессивно экономить энергию, урезая частоты существенным образом.

3. Драйвер i915 / Mesa

Intel активно перерабатывает графический стек — изменения в Mesa (25.x), переходы API и новые оптимизации иногда снимают старые обходы или меняют настройки таймингов. Неправильный матч между версией i915 в ядре и версией Mesa может привести к отключению оптимизаций или включению более консервативных путей исполнения.

4. Компилятор и бинарная оптимизация

GCC 15 изменил поведение ряда оптимизаций и ABI-деталей. Для вычислительно плотных тестов даже небольшие различия в inlining или векторизации влияют. Кроме того, LTO/PGO-поддержка и флаги оптимизации дистрибутива могли поменяться, так что «тот же» тест на новом toolchain — уже иной артефакт.

5. Микрокод/BIOS и терм-менеджмент

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

6. Изменение дефолтных профилей дистрибутива

Дистрибутивы с годами смещают акцент в сторону энергоэффективности и безопасности: systemd-твики, выключенные CPU-boost возможности, profilе «balanced», настройки schedtune для фоновых служб — всё это складывается.

Как системно диагностировать регрессию: чек-лист

Если есть собственный тестовый ноутбук — последовательность действий для локализации проблемы:

Собрать контрольные точки: старые ISO/снимки окружения, версии ядра, Mesa, GCC. Попробовать воспроизвести запуском старого образа и нового на том же железе.
Собрать метрики: turbostat, RAPL (powercap), intel_gpu_top, perf, dmesg. Сохранить логи до и после.
Отследить частоты и throttling: watch /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq, turbostat --interval 1.
Сравнить энергопотребление: package power via RAPL за тот же тестовый период.
Проверить микрокод/BIOS: откатить, если возможно, и протестировать. Часто vendors добавляют политику «safe by default».
Изолировать GPU и CPU: запуск CPU-only и GPU-only тестов, чтобы понять источник деградации.
Провести бенчмарк-бисект: менять версии ядра по одной, или версии Mesa по одной, чтобы найти коммит/релиз, который привёл к деградации.

Практические команды и инструменты (коротко)

turbostat — мониторинг частот, C-state и package power.
perf stat / perf record — профилирование CPU.
intel_gpu_top — загрузка GPU и частоты.
powertop — рекомендации по энергосбережению (и где включены «вредные» режимы).
phoronix test suite — повторяемые наборы тестов для регрессий.

Примеры из практики и параллели

Опыт с другими платформами показывает, что развитие Linux-стека обычно приводит к улучшениям: AMD в некоторых ревизиях давала приросты за счёт оптимизаций драйверов, Intel — за счёт совершенствования Mesa и i915. Но обратные кейсы не редкость: когда upstream-апдейт убирает локальную оптимизацию, или когда дефолты дистрибутива становятся более «экономными».

Типичный пример — апдейт Mesa, который меняет планировщик команд для GPU. На одном ноутбуке это давал +5–10% в некоторых тестах; на другом — падение, потому что ранее потенциально «опасный» обход был оптимизирован под конкретный чип/BIOS. Такая же логика применима и к микрокоду: безопасный патч уменьшает частоты и ухудшает бенчмарки, но повышает стабильность батареи и надежность в долгосрочной перспективе.

Что делать разработчикам дистрибутивов и вендорам

Тесная интеграция тестов производительности в CI: регрессии должны ловиться до выпуска релиза.
Предоставлять возможность простого переключения профилей (performance / balanced / battery) и документировать поведение.
Поддерживать матрицы совместимости между версиями i915 и Mesa, рекомендовать проверенные связки.
Отправлять репорты и патчи upstream: если регрессия в kernel/i915/Mesa — нужен быстрый фидбэк к разработчикам.

Прогнозы и тренды

Индустрия движется в сторону более сложных SoC: гибридные ядра, интегрированные NPU, tiled GPU. Это увеличивает число стыков, где может возникнуть рассогласование. В ближайшие релизы ядра и Mesa ожидается усиленная работа над корректной поддержкой гибридных архитектур и энергомоделей, а также улучшения в диагностике и инструментах. Параллельно, при росте роли «AI»-ускорителей на платах ноутбуков — производительность общего кода будет все сильнее зависеть от, казалось бы, отдельных компонент: от политики питания NPU до того, как драйверы делят шину памяти.

Небольшая заметка о дистрибутивах

Для тестирования в контролируемых виртуализованных средах иногда удобны отечественные сборки и облачные образы; например, для работы с виртуальными машинами и контейнерами можно рассмотреть НАЙС.ОС Cloud как один из вариантов платформы для воспроизводимых стендов.

Выводы

Регрессия Meteor Lake на Linux — тревожный, но объяснимый кейс. Когда железо становится сложнее, количество точек взаимодействия растёт, и даже позитивные обновления (более строгий микрокод, патчи безопасности, новые оптимизации компилятора) могут дать негативный эффект на показатели старых тестов. Задача инженерного сообщества — автоматизировать регрессионное тестирование, делать прозрачными профили энергопотребления и держать смежные стеки (ядро, Mesa, микрокод, компилятор) в согласованности.

Вовлекающий вопрос читателю

Сталкивались ли вы с похожими регрессиями после апдейтов ядра или драйверов? Какие инструменты и практики в ваших проектах помогли быстро локализовать проблему — bisect ядра, откат микрокода, профильные тесты? Поделитесь кейсами и любимыми командами для диагностики — это поможет составить практический набор для других тестировщиков.