Co nowego w Linux kernel 7.2 dla serwerów VPS

Co nowego w jądrze Linux 7.2

Jądro Linux 7.2 zostało wydane 16 sierpnia 2026 roku. Zmianą wartą uwagi jest szeregowanie uwzględniające pamięć podręczną (cache aware scheduling), zaimplementowane w ramach nowej opcji CONFIG_SCHED_CACHE. Harmonogram zadań stara się teraz utrzymywać wątki jednego procesu na procesorach współdzielących ten sam poziom pamięci podręcznej ostatniego poziomu (LLC). Żadna inna zmiana w tym wydaniu nie wpływa na sposób rozmieszczania obciążenia na procesorze.

Pozostałe nowości w wersji 7.2 w skrócie: przebudowa ścieżki szybkich zatwierdzeń (fast commit) w systemie ext4, usprawnienia w MGLRU (kod odzyskiwania pamięci oparty na algorytmie wielogeneracyjnym LRU), nowy cel mapowania urządzeń dm-inlinecrypt dla szyfrowania blokowego w locie oraz usunięcie ostatniego wywołania strncpy() ze źródeł jądra.

Jeden fakt decyduje o tym, czy główna nowość przyniesie korzyści w danym środowisku, dlatego jest omawiany jako pierwszy. Równoważenie obciążenia uwzględniające pamięć podręczną aktywuje się tylko wtedy, gdy węzeł NUMA (non-uniform memory access) zawiera więcej niż jeden poziom LLC. Maszyny wirtualne typu VPS zazwyczaj nie widzą takiej topologii, więc w większości przypadków kod jest kompilowany, ale nigdy nie zostaje uruchomiony. Weryfikacja tego stanu wymaga dwóch poleceń, opisanych w sekcji "Czy VPS widzi te zmiany" poniżej.

Każde twierdzenie techniczne na tej stronie pochodzi z dziennika zmian wersji 7.2 oraz z samej serii łatek dotyczących szeregowania uwzględniającego pamięć podręczną, zweryfikowanych 18 sierpnia 2026 roku. Źródła zostały wymienione pod koniec dokumentu, co umożliwia porównanie ich z działaniem własnego jądra.

Dlaczego scheduler musi uwzględniać pamięć podręczną

Współczesny gniazdo procesora serwerowego nie posiada jednej pamięci podręcznej ostatniego poziomu (LLC). Pakiet AMD EPYC zbudowany jest z kilku kompleksów rdzeni, z których każdy posiada własną pamięć L3. Nowsze jednostki Intel Xeon również dzielą gniazdo na więcej niż jedną domenę pamięci podręcznej. W rezultacie pojedynczy węzeł NUMA może zawierać cztery, osiem lub więcej oddzielnych pamięci LLC, a dwa wątki tego samego programu mogą zostać przypisane do różnych domen.

Takie rozmieszczenie generuje opóźnienia. Gdy dwa wątki współdzielą stronę pamięci, znajdując się w różnych domenach LLC, każda pamięć podręczna przechowuje własną kopię linii danych. Zapis po jednej stronie unieważnia kopię po drugiej, co zmusza kolejny odczyt do przejścia przez magistralę połączeniową lub sięgnięcia do pamięci głównej. Zjawisko to nazywane jest cache bouncing. Objawia się ono jako cykle procesora spędzone na oczekiwaniu, a nie jako czas bezczynności, dlatego łatwo je przeoczyć podczas monitorowania średniego obciążenia (load average).

Przed wersją 7.2 mechanizm równoważenia obciążenia (load balancer) rozmieszczał zadania w oparciu o obciążenie, wykorzystanie zasobów i dostępność bezczynnych rdzeni. Nie posiadał on informacji o tym, że dwa zadania odczytują ten sam obszar pamięci. Wersja 7.2 wprowadza takie rozwiązanie, wykorzystując przybliżenie, które nie obciąża obliczeniowo systemu: wątki jednego procesu współdzielą przestrzeń adresową, więc należy je traktować jako prawdopodobne źródła współdzielenia danych.

Wybór preferowanego LLC przez jądro systemu

Śledzenie jest przypisane do procesu w mm_struct, strukturze jądra reprezentującej jedną przestrzeń adresową. Jądro okresowo próbkuje, gdzie uruchomione są wątki danego procesu i zlicza dla każdego LLC, jaka część procesu znajduje się w danym obszarze. LLC z największym udziałem staje się preferowanym LLC dla całego procesu, a ta pojedyncza wartość jest później wykorzystywana przy podejmowaniu decyzji.

Wykorzystują ją dwie ścieżki. Podczas wybudzania scheduler preferuje wybór procesora w obrębie preferowanego LLC procesu, zamiast wybierać dowolny bezczynny procesor w węźle. Podczas równoważenia obciążenia, gdy zadania muszą zostać przeniesione między grupami schedulera, system preferuje przenoszenie zadań, które już preferują docelowe LLC, i unika przenoszenia zadania z preferowanego przez nie LLC.

Mechanizmy ochronne są równie istotne co sama funkcja, ponieważ upakowanie wszystkich wątków obciążonego procesu w jednej domenie pamięci podręcznej może doprowadzić do jej przeciążenia, podczas gdy reszta gniazda pozostaje bezczynna. Parametry konfiguracyjne znajdują się w debugfs, systemie plików debugowania jądra, pod ścieżką /sys/kernel/debug/sched/:

• llc_aggr_tolerance, wartość od 0 do 100, określa stopień agregacji jądra. 0 wyłącza planowanie uwzględniające pamięć podręczną w czasie wykonywania. 1 to ustawienie ostrożne: proces, którego RSS (resident set size, rozmiar pamięci rezydentnej) jest większy niż LLC lub który uruchamia więcej wątków niż liczba rdzeni w LLC, pozostaje w bieżącej lokalizacji. 100 agreguje proces niezależnie od jego rozmiaru czy liczby wątków.
• llc_overload_pct, wartość domyślna 50, to średnie wykorzystanie, powyżej którego preferowane LLC jest uznawane za zajęte.
• llc_imb_pct, wartość domyślna 20, ogranicza nierównowagę, jaką może wywołać migracja agregująca, gdy preferowane LLC przekroczy punkt przeciążenia.
• llc_epoch_period, wartość domyślna 10 ms, określa częstotliwość zbierania danych o zajętości.
• llc_epoch_affinity_timeout, wartość domyślna 50 ms, określa czas, przez jaki nieaktywny proces zachowuje swoje preferencje, zanim jądro je usunie.

Przed wprowadzeniem jakichkolwiek zmian należy odczytać bieżące wartości, ponieważ dystrybucje mogą dostarczać różne ustawienia domyślne: sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance.

Które obciążenia mogą zyskać, a które nie

Poniższe liczby to wartości opublikowane wraz z serią poprawek, zmierzone na sprzęcie klasy serwerowej, w niektórych przypadkach przy agresywnym ustawieniu tolerancji. Należy traktować je jako optymistyczny scenariusz na sprzęcie typu bare metal, a nie jako gwarancję wydajności dla własnej infrastruktury.

[
  {
    "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
  }
]

Wynik Hackbench z jedną grupą poprawił się o 30.57%, a przepustowość ChaCha20 na procesorach AMD Genoa wzrosła o 44%. Wszystkie 3 wyniki uzyskano na serwerowym sprzęcie z wieloma LLC, w pełni kontrolowanym przez testera.

Charakterystyka obciążenia, które może zyskać, wygląda następująco:

• Wiele wątków w jednym procesie, co pozwala na grupowanie.
• Rzeczywiste współdzielenie danych między wątkami, co sprawia, że przenoszenie linii pamięci podręcznej generuje realny koszt.
• Zestaw roboczy mieszczący się w jednym LLC, ponieważ procesu większego niż pamięć podręczna nie da się zoptymalizować pod kątem lokalności poprzez jego przeniesienie.
• Wolne zasoby na maszynie, dzięki czemu scheduler ma realny wybór miejsca dla kolejnego wątku.

Przypadki, w których nie można nic zyskać:

• Maszyna pracująca przy pełnym obciążeniu. Każdy CPU jest zajęty, więc rozmieszczenie jest wymuszone, a deklarowane zyski zanikają.
• Procesy jednowątkowe oraz pule niezależnych procesów, które nie współdzielą danych.
• Zestaw roboczy znacznie większy niż LLC, co ustawienie llc_aggr_tolerance celowo pomija.
• Węzeł zgłaszający tylko jeden LLC, gdzie funkcja w ogóle się nie aktywuje.

Istnieje również koszt tego rozwiązania, o czym otwarcie informuje dokumentacja serii. Gromadzenie danych o zajętości jest pracą wykonywaną w kontekście zadania, a niektóre testy wykazały pogorszenie opóźnień żądań, ponieważ praca ta opóźniała powrót zadania do przestrzeni użytkownika. Agregacja może również zwiększyć wariancję opóźnień, nawet jeśli średnia przepustowość ulegnie poprawie. Jeśli priorytetem jest ogon rozkładu (tail latency), a nie średnia, należy przeprowadzić własne pomiary.

Czy gość VPS widzi te mechanizmy

Odpowiedź zależy od dwóch faktów.

Po pierwsze, funkcja ta jest ograniczona przez topologię. Równoważenie obciążenia z uwzględnieniem pamięci podręcznej (cache aware load balancing) jest aktywowane tylko wtedy, gdy wewnątrz jednego węzła NUMA istnieje więcej niż jeden LLC, co jądro rejestruje podczas konfiguracji topologii. Jeśli węzeł zgłasza pojedynczy LLC, ścieżka uwzględniająca pamięć podręczną pozostaje nieaktywna, niezależnie od ustawień parametrów.

Po drugie, topologia pamięci podręcznej odczytywana przez gościa nie jest topologią hosta. Jest to model procesora prezentowany przez hypervisor. Domyślny gość KVM (kernel based virtual machine) zazwyczaj nie otrzymuje rzeczywistego układu L3 hosta, więc gość operuje na uproszczonym obrazie.

Sprawdź, co widzi Twój gość:

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

index3 to pamięć podręczna L3 na większości procesorów x86. Jeden wiersz wymieniający wszystkie vCPU oznacza, że gość widzi pojedynczy LLC, więc funkcja nie ma czego optymalizować. No such file or directory oznacza, że gościowi w ogóle nie udostępniono L3, przez co traktuje on niższy poziom pamięci podręcznej jako ostatni, z granicami wyznaczonymi przez hypervisor, a nie przez fizyczną architekturę krzemu.

Istnieje również problem podwójnego szeregowania (double scheduling), co jest istotnym zastrzeżeniem dla każdego najemcy. Jądro gościa umieszcza wątki na vCPU. Jądro hosta umieszcza te wątki vCPU na rdzeniach fizycznych. Gość, który starannie grupuje cztery wątki na vCPU od 0 do 3, wyraża preferencję dotyczącą czterech wątków hosta, podczas gdy host może swobodnie umieścić je w różnych domenach pamięci podręcznej i później je przenieść. Decyzja gościa nie jest błędna, po prostu nie jest ostateczna. To ta sama granica warstw, która powoduje czas kradziony (steal time) pozostawiany przez hałaśliwego sąsiada na Twoich vCPU.

Gdzie zatem ta funkcja dotyczy najemcy VPS? W dwóch przypadkach. W planach, gdzie topologia jest rzeczywista, a nie syntetyczna, takich jak dedykowane rdzenie lub większe instancje z przekazanym układem (passed-through layout), scheduler gościa podejmuje decyzję dotyczącą istniejącego sprzętu. Ponadto, w jądrze hosta dostawcy, optymalizacja rozmieszczenia wątków vCPU z uwzględnieniem pamięci podręcznej jest korzyścią dla dostawcy, a nie dla Ciebie. Układ pamięci podręcznej różni się również w zależności od architektury, co stanowi kolejną zmienną przy porównywaniu VPS z architekturą Arm z VPS z architekturą x86.

Pomiar zachowania pamięci podręcznej wewnątrz gościa jest trudniejszy niż na sprzęcie fizycznym (bare metal). perf stat -e cache-misses często zgłasza <not supported>, ponieważ hypervisor nie udostępnia gościom PMU (performance monitoring unit). Zamiast tego zmierz przepustowość i opóźnienia własnej aplikacji, używając przełącznika w debugfs jako metody porównawczej między dwoma uruchomieniami.

Sprawdzenie, czy jądro posiada 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 oznacza, że jądro zostało zbudowane z tą opcją. Wiersz o treści # CONFIG_SCHED_CACHE is not set oznacza, że opcja istnieje w danej wersji, ale dystrybucja ją wyłączyła. Brak jakiegokolwiek wyniku zazwyczaj oznacza, że jądro jest starsze niż ta opcja, co potwierdzi uname -r. Niektóre minimalne obrazy chmurowe nie zawierają pliku /boot/config-*; w takim przypadku należy odczytać zcat /proc/config.gz, co zadziała tylko wtedy, gdy jądro zbudowano z CONFIG_IKCONFIG_PROC.

Wiersz ls wyświetla parametry llc_*, jeśli funkcja została wkompilowana. Jeśli polecenie nie zwraca nic mimo CONFIG_SCHED_CACHE=y, należy najpierw zamontować debugfs za pomocą sudo mount -t debugfs none /sys/kernel/debug.

Aby porównać obciążenie z włączoną i wyłączoną funkcją, należy najpierw zapisać bieżącą wartość, ponieważ trzeba będzie ją przywrócić:

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

Uruchom test wydajności, przywróć zapisaną wcześniej wartość i uruchom test ponownie. Zmiany w debugfs nie przetrwają restartu, co jest pożądane podczas testów.

Kiedy jądro z głównej linii trafi do dystrybucji

Wersja mainline nie jest tym, co uruchamia Twój VPS. Wersja w uname -r pochodzi od Twojej dystrybucji, a każda z nich ma własną ścieżkę przenoszenia wydań mainline na serwery użytkowników.

Fedora aktualizuje swoje stabilne wydania do nowych jąder mainline w trakcie ich cyklu wsparcia, więc sudo dnf upgrade --refresh wraz z restartem to cały proces, który zazwyczaj pozwala użytkownikowi najszybciej przetestować nowe jądro. Ten cykl wydawniczy jest częścią wyboru, którego dokonujesz, uruchamiając Fedora Server na VPS.

Ubuntu dostarcza nowe jądro wraz z każdym wydaniem co sześć miesięcy, a następnie przenosi je do poprzedniego wydania o długoterminowym wsparciu (LTS) poprzez stos HWE (hardware enablement). Według stanu na sierpień 2026, Ubuntu 24.04 LTS nadal instaluje 6.8 z kwietnia 2024 jako jądro GA, podczas gdy jego stos HWE przeszedł na 6.14 w sierpniu 2025 i na 6.17 w lutym 2026. To realistyczna skala czasowa: wydanie mainline z sierpnia 2026 trafia do stosu LTS HWE około rok później.

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

Debian stable utrzymuje jedno jądro przez cały okres życia wydania i oferuje nowsze wersje poprzez backports, które aktywuje się dla poszczególnych pakietów:

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

Po wykonaniu dowolnej z powyższych czynności należy zrestartować system i potwierdzić zmiany za pomocą uname -r oraz wspomnianego wyżej grep. Nowego jądra nie można załadować w locie: live kernel patching na VPS zastępuje kod poszczególnych funkcji w działającym jądrze, ale nie może zmieniać układów struktur ani dodawać plików debugfs. Harmonogramowanie uwzględniające pamięć podręczną (cache aware scheduling) wykonuje obie te operacje, ponieważ dodaje pola do mm_struct, dlatego zmiany te są dostępne tylko po uruchomieniu nowego jądra.

Dwie praktyczne wskazówki. Pozostaw stare jądro jako opcję rozruchową, dopóki nowe nie obsłuży Twojego obciążenia przez pewien czas; do tego służy przypinanie jądra rozruchowego na VPS. Monitoruj również /boot, ponieważ mała partycja rozruchowa VPS zapełnia się po kilku aktualizacjach jądra, co opisano w usuwanie starych jąder w Ubuntu.

Ostatnia uwaga dotycząca własności. Na VPS typu KVM jądro gościa należy do Ciebie: wybierasz je, uruchamiasz i możesz przywrócić poprzednią wersję. Jądro hosta należy do dostawcy i żadne ustawienie wewnątrz gościa nie zmieni harmonogramu używanego przez hypervisor. Dlatego informacja o zmianach w harmonogramowaniu jest tylko częścią obrazu dla użytkownika, a Ty masz kontrolę wyłącznie nad stroną gościa.

Źródła wykorzystane na tej stronie

• Podsumowanie zmian wersji 7.2 w serwisie kernelnewbies.org, dotyczące daty wydania 16 sierpnia 2026 oraz zmian niezwiązanych z harmonogramem zadań.
• Omówienie serii zmian dotyczących szeregowania z uwzględnieniem pamięci podręcznej (cache aware scheduling) w serwisie LWN pod adresami lwn.net/Articles/1041668 oraz lwn.net/Articles/1058288, dotyczące parametrów debugfs, mechanizmu preferencji dla poszczególnych procesów oraz raportowanych wyników testów wydajnościowych.
• Łatka ograniczająca funkcjonalność w oparciu o topologię, "sched/cache: Introduce sched_cache_present", określająca zasadę, według której równoważenie obciążenia z uwzględnieniem pamięci podręcznej wymaga więcej niż jednego poziomu LLC w węźle NUMA.

Informacje o poprzednim wydaniu znajdują się w sekcji co zmieniło się w jądrze Linux 7.1. Informacje o sposobie nadawania numerów wersji znajdują się w sekcji oś czasu historii jądra Linux.

FAQ

Czy planowanie z uwzględnieniem pamięci podręcznej (cache aware scheduling) w systemie Linux 7.2 przyspiesza działanie VPS?

Zazwyczaj nie. Funkcja ta aktywuje się tylko wtedy, gdy węzeł NUMA zgłasza więcej niż jedną pamięć podręczną ostatniego poziomu (LLC), a typowy gość KVM nie otrzymuje informacji o takiej topologii, więc kod nie jest uruchamiany. Tam, gdzie funkcja działa, gość jest nadal planowany dwukrotnie: jądro gościa wybiera vCPU, a jądro hosta decyduje, na którym fizycznym rdzeniu uruchomiony zostanie wątek tego vCPU, więc decyzja o pamięci podręcznej po stronie gościa może zostać zniwelowana przez hosta. Uruchom cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u wewnątrz gościa. Jeden wiersz obejmujący wszystkie vCPU oznacza, że funkcja nie ma czego optymalizować.

Jak sprawdzić, czy jądro posiada opcję CONFIG_SCHED_CACHE?

Uruchom grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r). Wynik CONFIG_SCHED_CACHE=y oznacza, że opcja jest wbudowana, # CONFIG_SCHED_CACHE is not set oznacza, że dystrybucja ją wyłączyła, a brak wyniku oznacza, że jądro jest starsze niż ta opcja. Jeśli obraz nie posiada pliku /boot/config-*, spróbuj zcat /proc/config.gz, który istnieje tylko w jądrach zbudowanych z CONFIG_IKCONFIG_PROC. Można to potwierdzić w czasie wykonywania za pomocą sudo ls /sys/kernel/debug/sched/ | grep -i llc, który wyświetla parametry llc_*, jeśli funkcja jest dostępna.

Jak wyłączyć planowanie z uwzględnieniem pamięci podręcznej bez restartu?

Zapisz 0 do parametru tolerancji: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. Wyłącza to funkcję w czasie pracy systemu, co pozwala na czyste porównanie A/B w testach wydajnościowych. Najpierw odczytaj bieżącą wartość za pomocą sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance i zapisz ją ponownie po zakończeniu testów, ponieważ wartości domyślne różnią się między kompilacjami. Żadne zmiany zapisane w debugfs nie przetrwają restartu. Jeśli cat zwraca No such file or directory, oznacza to, że jądro nie ma wkompilowanej tej funkcji i nie ma czego wyłączać.

Kiedy Ubuntu lub Debian udostępnią jądro oparte na wersji 7.2?

Fedora przenosi stabilne wydania na nowe jądra główne (mainline), więc trafiają one tam najpierw poprzez standardową aktualizację dnf upgrade i restart. Ubuntu dostarcza nowe jądra wraz z każdym półrocznym wydaniem i przenosi je do poprzedniego wydania LTS poprzez stos HWE, a historyczne opóźnienie wynosi około roku: według stanu na sierpień 2026 stos HWE dla 24.04 LTS korzysta z wersji 6.17 z lutego 2026, podczas gdy jądro GA to nadal 6.8. Debian stable utrzymuje jedno jądro dla danego wydania i oferuje nowsze wersje poprzez trixie-backports, które instaluje się jako pojedyncze pakiety za pomocą apt install -t trixie-backports linux-image-amd64.