Linux 7.2: что нового в ядре для VPS

Что нового в ядре Linux 7.2

Ядро Linux 7.2 было выпущено 16 августа 2026 года. Основное изменение, заслуживающее внимания — это планировщик с учетом кэша (cache aware scheduling), реализованный с помощью новой опции CONFIG_SCHED_CACHE. Теперь планировщик стремится удерживать потоки одного процесса на ядрах CPU, которые используют общий кэш последнего уровня (LLC). Других изменений в механизме распределения нагрузки на CPU в этом релизе нет.

Остальные новшества 7.2 кратко: переработка пути быстрой фиксации (fast commit) в ext4, улучшения в MGLRU (алгоритм вытеснения страниц памяти на основе нескольких поколений), новая цель dm-inlinecrypt для device mapper, предназначенная для встроенного шифрования блочных устройств, и удаление последнего вызова strncpy() из исходного кода ядра.

Один факт определяет, будет ли основная функция полезна в вашем случае. Балансировка нагрузки с учетом кэша активируется только в том случае, если узел NUMA (non-uniform memory access) содержит более одного LLC. Виртуальные машины (VPS) обычно не видят такую топологию, поэтому в большинстве гостевых систем код будет скомпилирован, но никогда не задействован. Проверить это можно двумя командами, приведенными в разделе «Видит ли VPS-гость эти изменения» ниже.

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

Зачем планировщику знать о кэшах

Современный процессорный сокет не имеет одного общего кэша последнего уровня. Процессор AMD EPYC состоит из нескольких комплексов ядер, и каждый комплекс обладает собственным кэшем L3. В современных процессорах Intel Xeon сокет также разделен на несколько доменов кэширования. Таким образом, один узел NUMA может содержать четыре, восемь или более отдельных LLC, и два потока одной программы могут оказаться в разных доменах.

Такое размещение требует времени. Когда два потока используют общую страницу памяти из разных LLC, каждый кэш хранит собственную копию строки. Запись с одной стороны делает копию на другой стороне недействительной, поэтому следующее чтение вынуждено проходить через межпроцессорное соединение или обращаться к основной памяти. Это называется «прыгающим кэшем» (cache bouncing). Данная проблема проявляется как циклы ожидания, а не как простой процессора, поэтому её легко упустить из виду при мониторинге load average.

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

Как ядро выбирает предпочтительный LLC

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

Затем это значение используется в двух сценариях. При пробуждении планировщик отдает предпочтение CPU в составе предпочтительного LLC процесса, вместо того чтобы выбирать любой свободный CPU в узле. Во время балансировки нагрузки, когда задачи должны перемещаться между группами планировщика, система стремится переносить задачи, для которых целевой LLC уже является предпочтительным, и избегает перемещения задачи из того LLC, который она предпочитает.

Ограничители важны не меньше, чем сама функция, поскольку размещение всех потоков ресурсоемкого процесса в одном домене кэша может привести к его перегрузке, в то время как остальная часть сокета будет простаивать. Параметры настройки находятся в debugfs, отладочной файловой системе ядра, по пути /sys/kernel/debug/sched/:

• llc_aggr_tolerance, значение от 0 до 100, определяет степень агрегации, выполняемой ядром. 0 отключает планирование с учетом кэша во время работы. 1 — это осторожный режим: процесс, чей RSS (resident set size, объем резидентной памяти) превышает размер LLC или который запускает больше потоков, чем количество ядер в LLC, остается на месте. 100 выполняет агрегацию независимо от размера или количества потоков.
• llc_overload_pct, по умолчанию 50, — это уровень средней загрузки, выше которого предпочтительный LLC считается занятым.
• llc_imb_pct, по умолчанию 20, ограничивает дисбаланс, который может возникнуть при миграции с агрегацией, если предпочтительный LLC превысил порог перегрузки.
• llc_epoch_period, по умолчанию 10 мс, определяет частоту сбора данных о занятости.
• llc_epoch_affinity_timeout, по умолчанию 50 мс, определяет время, в течение которого неактивный процесс сохраняет свое предпочтение, прежде чем ядро его сбросит.

Перед внесением изменений считайте текущие значения, так как в разных дистрибутивах могут быть установлены разные настройки по умолчанию: sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance.

Какие рабочие нагрузки получают преимущество, а какие нет

Приведенные ниже цифры — это показатели, опубликованные вместе с серией патчей. Они измерены на серверном оборудовании, причем некоторые из них получены при установке параметра допуска в агрессивный режим. Рассматривайте их как лучший сценарий на «голом железе», а не как гарантию для вашей системы.

[
  {
    "label": "hackbench, 1 group, Xeon Sapphire Rapids",
    "gain_pct": 30.57
  },
  {
    "label": "schbench, 4 threads, p99 wakeup latency, Sapphire Rapids",
    "gain_pct": 37.78
  },
  {
    "label": "ChaCha20 throughput, AMD Genoa, aggressive tolerance",
    "gain_pct": 44
  }
]

Производительность Hackbench с одной группой выросла на 30.57%, а пропускная способность ChaCha20 на AMD Genoa увеличилась на 44%. Все 3 результатов были получены на серверном оборудовании с несколькими LLC, которое тестировщик полностью контролировал.

Характеристики рабочей нагрузки, которая получает преимущество, выглядят так:

• Более одного потока в рамках одного процесса, чтобы было что группировать.
• Реальное совместное использование данных между этими потоками, из-за чего перемещение строки кэша становится реальными издержками.
• Рабочий набор данных помещается в один LLC, так как для процесса, размер которого превышает кэш, невозможно обеспечить локальность кэша путем его перемещения.
• Наличие свободных ресурсов на машине, чтобы у планировщика был реальный выбор, куда поместить следующий поток.

Случаи, когда выигрыша не будет:

• Машина уже работает на полной мощности. Все CPU заняты, поэтому размещение принудительно, и заявленный прирост нивелируется.
• Однопоточные процессы и пулы независимых процессов, которые не обмениваются данными.
• Рабочий набор данных значительно больше объема LLC, что параметр llc_aggr_tolerance намеренно игнорирует.
• Узел, который сообщает об одном LLC, где данная функция вообще не активируется.

Существует и обратная сторона — затраты, о которых в серии патчей говорится открыто. Сбор данных о заполненности кэша выполняется в контексте задачи, и в некоторых запусках наблюдалось увеличение задержки запросов, так как эта работа задерживала возврат задачи в пространство пользователя. Агрегация также может увеличить разброс задержек, даже если средняя пропускная способность растет. Если вас интересуют «хвосты» распределения (tail latency), а не средние значения, измеряйте их самостоятельно.

Видит ли это гостевая система на VPS

Ответ на этот вопрос определяют два факта.

Во-первых, работа функции зависит от топологии. Балансировка нагрузки с учетом кэша включается только тогда, когда внутри одного узла NUMA существует более одного LLC, и ядро фиксирует это при настройке топологии. Если узел сообщает о наличии только одного LLC, путь с учетом кэша остается неактивным, независимо от установленных параметров.

Во-вторых, топология кэша, которую видит ваша гостевая система, не совпадает с топологией хоста. Она определяется моделью процессора, которую предоставляет гипервизор. Гостевой системе KVM (kernel based virtual machine) по умолчанию обычно не передается реальная структура L3-кэша хоста, поэтому гостевая ОС оперирует упрощенной схемой.

Проверьте, что видит ваша гостевая система:

systemd-detect-virt
lscpu --caches
cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u

index3 — это кэш L3 на большинстве процессоров x86. Если в выводе для каждого vCPU указана одна строка, значит, гостевая система видит единственный LLC, и функции нечего распределять. No such file or directory означает, что кэш L3 гостевой системе вообще не был предоставлен, и она воспринимает более низкий уровень кэша как последний, причем с границами, которые выдумал гипервизор, а не с теми, что заложены в кремнии.

Кроме того, существует проблема двойного планирования — это существенный нюанс для любого арендатора. Ядро гостевой системы размещает потоки на vCPU. Ядро хоста размещает эти потоки vCPU на физических ядрах. Гостевая система, которая старательно группирует четыре потока на vCPU с 0 по 3, выражает предпочтение относительно четырех потоков хоста, но хост волен разместить их в разных физических доменах кэша и переместить их позже. Решение гостевой системы не является ошибочным, оно просто не является окончательным. Это та же самая граница уровней, которая порождает время ожидания (steal time), которое оставляет на ваших vCPU «шумный сосед».

Так где же эта функция затрагивает арендатора VPS? В двух случаях. На тарифах, где топология является реальной, а не синтетической (например, выделенные ядра или крупные инстансы с проброшенной структурой), планировщик гостевой системы принимает решения относительно существующего оборудования. И на уровне ядра хоста провайдера, где размещение потоков vCPU с учетом кэша — это преимущество провайдера, а не ваше. Структура кэша также различается в зависимости от архитектуры, что является еще одной переменной при сравнении VPS на базе Arm и VPS на базе x86.

Измерение поведения кэша внутри гостевой системы сложнее, чем на «железе». perf stat -e cache-misses часто сообщает <not supported>, поскольку гипервизор не предоставляет гостевым системам доступ к PMU (performance monitoring unit). Вместо этого измеряйте пропускную способность и задержки вашего собственного приложения, используя параметр debugfs в качестве переключателя между двумя запусками.

Проверка наличия CONFIG_SCHED_CACHE в ядре

uname -r
grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r) || echo 'not set in this build'
sudo ls /sys/kernel/debug/sched/ | grep -i llc

CONFIG_SCHED_CACHE=y означает, что ваше ядро было собрано с этой опцией. Строка # CONFIG_SCHED_CACHE is not set указывает на то, что опция существует в данной версии, но была отключена в вашем дистрибутиве. Отсутствие вывода обычно означает, что версия ядра старше этой опции, что можно подтвердить с помощью uname -r. В некоторых минималистичных образах для облачных сред файл /boot/config-* отсутствует; в таких случаях следует использовать zcat /proc/config.gz, что работает только при условии, что ядро было собрано с CONFIG_IKCONFIG_PROC.

Строка ls выводит параметры llc_*, если функция была включена при компиляции. Если вывод пуст, хотя CONFIG_SCHED_CACHE=y, сначала смонтируйте debugfs командой sudo mount -t debugfs none /sys/kernel/debug.

Чтобы сравнить производительность вашей нагрузки с включенной и выключенной функцией, сначала сохраните текущее значение, так как его потребуется вернуть обратно:

sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance
sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'

Запустите тест производительности, запишите ранее сохраненное значение обратно и повторите тест. Записи в debugfs не сохраняются после перезагрузки, что и требуется при проведении тестирования.

Когда ядро из дистрибутива получит версию 7.2

Mainline-ядро — это не то, что загружается на вашем VPS. Версия в uname -r предоставлена вашим дистрибутивом, и у каждого дистрибутива свой путь от релиза mainline до вашего сервера.

Fedora обновляет свои стабильные релизы до новых версий mainline-ядер в течение всего срока их поддержки, поэтому sudo dnf upgrade --refresh и перезагрузка — это весь процесс, и обычно это первое место, где пользователь может попробовать новое ядро. Этот темп обновлений — часть того, что вы выбираете, когда используете Fedora Server на VPS.

Ubuntu выпускает новое ядро с каждым полугодовым релизом, а затем переносит его в предыдущий релиз с долгосрочной поддержкой (LTS) через стек HWE (hardware enablement). По состоянию на 12 октября 2026 года в таблице HWE от Canonical ядро 6.8 от апреля 2024 года указано как GA-ядро для Ubuntu 24.04 LTS. Стек HWE для 24.04 перешел на 6.17 в феврале 2026 года и на 7.0 в августе 2026 года, и это HWE-ядро 7.0 поддерживается до апреля 2029 года. Таким образом, установка стека HWE для 24.04 сегодня дает вам 7.0, которое вышло раньше CONFIG_SCHED_CACHE. Сам процесс перехода быстрый: 7.0 появилось в Ubuntu 26.04 LTS в апреле 2026 года и попало в стек HWE для 24.04 в августе 2026 года, спустя четыре месяца. Однако 7.2 не входит в этот план. 1 сентября 2026 года команда разработчиков ядра Canonical объявила, что Ubuntu 26.10, выход которой запланирован на 15 октября 2026 года, будет использовать Linux 7.3 вместо 7.2, поэтому ядро Ubuntu новее 7.0 будет версии 7.3 или выше. 7.3 базируется на 7.2, и как только вы его получите, grep выше покажет, включена ли эта опция в сборке Ubuntu.

apt-cache policy linux-generic-hwe-24.04
sudo apt install --install-recommends linux-generic-hwe-24.04

Debian stable сохраняет одно ядро на протяжении всего жизненного цикла релиза и предлагает более новые версии через backports, которые вы подключаете для отдельных пакетов:

echo 'deb http://deb.debian.org/debian trixie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list
sudo apt update
sudo apt install -t trixie-backports linux-image-amd64

После выполнения любой из этих команд перезагрузитесь и проверьте результат с помощью uname -r и grep выше. Новое ядро нельзя загрузить «на лету»: live kernel patching на VPS заменяет код отдельных функций в работающем ядре, но не может изменять структуру данных или добавлять файлы в debugfs. Планировщик с учетом кэша (cache aware scheduling) делает и то, и другое, так как добавляет поля в mm_struct, поэтому он становится доступен только после загрузки нового ядра.

Два практических совета. Сохраняйте старое ядро загрузочным, пока новое не проработает под вашей нагрузкой некоторое время; для этого используется фиксация загружаемого ядра на VPS. И следите за /boot, так как небольшой загрузочный раздел VPS заполняется после нескольких обновлений ядра, как описано в очистке старых ядер в Ubuntu.

Последний момент касательно владения системой. На KVM VPS гостевое ядро принадлежит вам: вы выбираете его, загружаете и откатываете. Ядро хоста принадлежит вашему провайдеру, и никакие настройки внутри гостевой системы не изменят планировщик, который использует гипервизор. Поэтому примечание к релизу о работе планировщика — это лишь половина дела для арендатора, а та часть, которую вы контролируете, находится на стороне гостевой системы.

Источники, использованные для этой страницы

• Сводка изменений версии 7.2 на kernelnewbies.org, для даты релиза 16 августа 2026 года и изменений, не относящихся к планировщику.
• Обзор серии статей о планировании с учетом кэша (cache aware scheduling) на LWN lwn.net/Articles/1041668 и lwn.net/Articles/1058288, для параметров настройки debugfs, механизма предпочтений для конкретных процессов и указанных результатов тестирования.
• Патч, ограничивающий функциональность на основе топологии, "sched/cache: Introduce sched_cache_present", для правила, согласно которому балансировка нагрузки с учетом кэша требует наличия более одного LLC в узле NUMA.
• Таблица жизненного цикла HWE-ядер от Canonical HWE kernel lifecycle table и анонс ядра Ubuntu 26.10 kernel announcement от команды разработчиков ядра, изученные 12 октября 2026 года, для версий и дат выхода ядер Ubuntu.

Информацию о предыдущем релизе см. в что изменилось в ядре Linux 7.1. О том, как формировались номера версий, см. хронология истории ядра Linux.

FAQ

Ускоряет ли VPS планировщик с учетом кэша в Linux 7.2?

Обычно нет. Эта функция активируется только тогда, когда узел NUMA сообщает о наличии более одного кэша последнего уровня (LLC), а типичный гостевой KVM-образ не видит такой топологии, поэтому код не задействуется. Там, где он задействуется, планирование гостя всё равно происходит дважды: ваше ядро выбирает vCPU, а ядро хоста решает, на каком физическом ядре будет выполняться этот поток vCPU, поэтому решение гостевой системы по кэшу может быть отменено хостом. Выполните cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u в гостевой системе. Если одна строка охватывает все vCPU, значит, функции нечего оптимизировать.

Как проверить, содержит ли мое ядро CONFIG_SCHED_CACHE?

Выполните grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r). CONFIG_SCHED_CACHE=y означает, что функция встроена, # CONFIG_SCHED_CACHE is not set означает, что ваш дистрибутив отключил её, а отсутствие вывода означает, что ядро старше этой опции. Если в образе нет файла /boot/config-*, попробуйте zcat /proc/config.gz, который существует только в ядрах, собранных с CONFIG_IKCONFIG_PROC. Вы можете подтвердить наличие функции во время работы системы с помощью sudo ls /sys/kernel/debug/sched/ | grep -i llc, где перечислены параметры llc_*, если функция присутствует.

Как отключить планирование с учетом кэша без перезагрузки?

Запишите 0 в регулятор допуска: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. Это отключает функцию во время работы системы, что позволяет использовать её как чистый переключатель A/B для тестирования производительности. Сначала считайте текущее значение с помощью sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance и запишите его обратно после тестов, так как значения по умолчанию различаются в разных сборках. Никакие изменения в debugfs не сохраняются после перезагрузки. Если cat сообщает No such file or directory, значит, в вашем ядре эта функция не скомпилирована и отключать нечего.

Когда Ubuntu или Debian выпустят ядро на базе 7.2?

Fedora переводит стабильные релизы на новые основные версии ядер, поэтому там они появляются первыми через обычное dnf upgrade и перезагрузку. Ubuntu выпускает новые ядра с каждым полугодовым релизом и переносит их в предыдущие LTS через стек HWE. В таблице HWE от Canonical этот процесс для версии 7.0 занял четыре месяца: с Ubuntu 26.04 в апреле 2026 года до стека HWE для 24.04 в августе 2026 года, при этом GA-ядро для 24.04 до сих пор 6.8. Ubuntu может пропустить версию 7.2: по состоянию на 12 октября 2026 года, Ubuntu 26.10, выход которой намечен на 15 октября, ориентируется на 7.3, поэтому изменения в планировщике попадут в Ubuntu через 7.3 или более поздние версии. Debian stable сохраняет одно ядро для релиза и предлагает более новые через trixie-backports, которые устанавливаются по отдельности с помощью apt install -t trixie-backports linux-image-amd64.