Что нового в ядре 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 не сохраняются после перезагрузки, что и требуется при проведении тестирования.

Когда ядро из основной ветки появится в дистрибутиве

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

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

Ubuntu выпускает новое ядро с каждым полугодовым релизом, а затем переносит его в предыдущий релиз с долгосрочной поддержкой (LTS) через стек HWE (hardware enablement). По состоянию на август 2026 года, Ubuntu 24.04 LTS всё ещё устанавливает 6.8 от апреля 2024 года в качестве GA-ядра, в то время как её стек HWE перешёл на 6.14 в августе 2025 года и на 6.17 в феврале 2026 года. Это реалистичные сроки: релиз mainline от августа 2026 года попадает в LTS HWE стек примерно через год.

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 года и изменений, не связанных с планировщиком.
• Обзор серии статей о планировании с учетом кэша на lwn.net/Articles/1041668 и lwn.net/Articles/1058288, посвященный параметрам настройки через debugfs, механизму предпочтений для каждого процесса и опубликованным результатам тестов.
• Патч, ограничивающий использование функции в зависимости от топологии, "sched/cache: Introduce sched_cache_present", устанавливающий правило, согласно которому для балансировки нагрузки с учетом кэша требуется более одного LLC в узле NUMA.

Информацию о предыдущем релизе см. в разделе что изменилось в ядре 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; исторический разрыв составляет около года: по состоянию на август 2026 года стек HWE для 24.04 LTS использует версию 6.17 от февраля 2026 года, тогда как её базовое ядро (GA) всё ещё 6.8. Debian stable сохраняет одно ядро на весь цикл релиза и предлагает более новые через trixie-backports, которые устанавливаются по отдельности через apt install -t trixie-backports linux-image-amd64.