Linux 7.2 został wydany przez Linusa Torvaldsa 16 sierpnia 2026 r. To nie jest tylko kolejna inkrementacja numerka w cyklu mainline. W tej wersji zbiegło się kilka zmian, które są interesujące z punktu widzenia administratora Linuksa, DevOpsa i użytkownika stacji roboczej: cache-aware scheduling w schedulerze CPU, zmiany w reclaimingu pamięci, kolejny etap przebudowy obsługi swapu, USB4STREAM do przesyłania danych między hostami po USB4, usprawnienia Btrfs, nowy cel device-mappera dla inline encryption oraz sporo pracy przy sterownikach AMD, Intel, RISC-V i Apple Silicon.
Według kernel.org 28 sierpnia 2026 r. aktualną stabilną rewizją gałęzi 7.2 była już wersja 7.2.2, a równolegle dostępne były aktualizacje dla gałęzi 7.1, 6.18, 6.12, 6.6, 6.1, 5.15 i 5.10. To ważny kontekst: wersja 7.2 jest atrakcyjna dla testów i nowego sprzętu, ale w środowiskach produkcyjnych decyzja o migracji powinna wynikać z konkretnej potrzeby, a nie z samej daty wydania.
Co faktycznie zmienia Linux 7.2
Najbardziej medialną zmianą jest cache-aware scheduling. Scheduler Linuksa dostał mechanizmy, które pomagają lokować zadania współdzielące dane w obrębie tego samego Last Level Cache, czyli LLC. W praktyce chodzi o ograniczenie niepotrzebnego przerzucania pracy między grupami rdzeni, gdy taka migracja powoduje dodatkowe chybienia cache i kosztowne odwołania do pamięci. Na serwerach z wieloma rdzeniami, wieloma domenami LLC i topologią NUMA ta zmiana może mieć znaczenie większe niż na prostym laptopie z kilkoma rdzeniami.
Nie należy jednak czytać tego jako obietnicy uniwersalnego przyspieszenia każdej maszyny. Cache-aware scheduling może poprawić lokalność danych, ale efekt zależy od topologii CPU, rodzaju procesu, liczby wątków, presji na pamięć i tego, czy workload faktycznie cierpiał przez migracje między domenami cache. Dla admina oznacza to przede wszystkim jedno: jeśli utrzymujesz bazy danych, kolejki, analitykę, serwery JVM, workloads HPC albo intensywne CI, Linux 7.2 jest kandydatem do kontrolowanych benchmarków.
Pamięć, swap i Btrfs: mniej spektakularne, ale bardzo adminowe
Drugim obszarem wartym uwagi jest pamięć. Linux 7.2 zawiera usprawnienia w MGLRU, czyli Multi-Gen LRU. Mechanizmy reclaimingu pamięci decydują, które strony pozostają w RAM, które są wyrzucane z cache, a które mogą trafić do swapu. KernelNewbies opisuje w tej wersji porządki w pętli reclaimingu oraz obsłudze dirty writeback, ze wskazaniem na poprawę w wybranych scenariuszach, między innymi przy workloadach MongoDB z YCSB. Dla operatora systemów to sygnał, że warto mierzyć nie tylko średni throughput, ale również refaulty, opóźnienia ogonowe i zachowanie pod presją pamięci.
W Linux 7.2 kontynuowana jest też praca nad swap table. Czwarta faza tych zmian ujednolica alokację i rozliczanie swapu dla pamięci anonimowej oraz shmem w folios, redukuje statyczny narzut metadanych i poprawia synchronizację. W praktyce duże swapy powinny mieć mniejszy koszt administracyjny w pamięci jądra. Nie oznacza to, że swap nagle staje się zamiennikiem RAM-u, ale na hostach z dużymi przestrzeniami swap, kontenerami i workloadami podatnymi na chwilowe piki pamięci jest to kierunek korzystny.
Administratorzy Btrfs także mają powód, aby odnotować tę wersję. Linux 7.2 włącza large folios domyślnie dla Btrfs, dodaje eksperymentalne huge folios do 2 MB, nowy ioctl GET_CSUMS oraz usprawnienia przy zapisie sekwencyjnym i direct I/O. Jeżeli używasz Btrfs pod snapshoty, kontenery, stacje developerskie albo serwery plików, testy powinny obejmować realny profil I/O, a nie wyłącznie syntetyczne wyniki fio uruchomione na pustym wolumenie.
USB4STREAM: prosty kanał między dwoma Linuksami
Jedną z ciekawszych nowości administracyjnych jest USB4STREAM. Linux miał już obsługę thunderbolt_net, ale Linux 7.2 dodaje możliwość przesyłania surowych strumieni danych przez kabel USB4. Sterownik wystawia urządzenia w rodzaju /dev/tbstreamX, z których można korzystać zwykłymi operacjami read i write. To proste, ale bardzo unixowe: jeżeli aplikacja potrafi czytać z pliku albo pisać do pliku, można ją potencjalnie wpiąć w taki kanał.
Nie jest to zamiennik całej sieci, routingu, TLS i autoryzacji. To raczej narzędzie do zadań specjalnych: szybka migracja danych między dwiema stacjami, debugowanie, transfer obrazów dysków, laboratoryjne scenariusze recovery albo środowiska, w których klasyczny networking nie jest dostępny lub jest celowo wyłączony. Warto potraktować USB4STREAM jak lokalny, fizyczny kanał transportowy, który nadal wymaga dyscypliny operacyjnej: kontroli dostępu do urządzeń, jasnych procedur i testów integralności danych.
# Przykładowy test koncepcyjny USB4STREAM na dwóch hostach z Linuksem 7.2+
# host A: odbiór strumienia do pliku obrazu
sudo cat /dev/tbstream0 > obraz-z-hosta-b.raw
# host B: wysłanie danych przez urządzenie tbstream
sudo dd if=/dev/nvme0n1 bs=16M status=progress > /dev/tbstream0
# Po transferze warto porównać sumy kontrolne źródła i kopii
sha256sum obraz-z-hosta-b.rawPowyższy przykład nie jest gotową procedurą produkcyjną. Ma pokazać model pracy: urządzenie znakowe lub plikowe jako końcówka strumienia. Przed użyciem w realnym recovery trzeba sprawdzić nazwy urządzeń, uprawnienia, przepustowość, zachowanie po przerwaniu kabla oraz to, czy transfer nie omija mechanizmów szyfrowania wymaganych w danej organizacji.
Bezpieczeństwo i izolacja: openat2, dm-inlinecrypt i mniej pułapek
Linux 7.2 dodaje też zmiany, które łatwo przeoczyć, a które są istotne dla bezpieczeństwa usług. Wśród nich jest flaga OPENAT2_REGULAR dla openat2, pozwalająca odmówić otwarcia obiektów innych niż zwykłe pliki. To mechanizm przydatny dla daemonów i narzędzi, które pracują na ścieżkach dostarczanych przez użytkownika, system pluginów albo automatyzację. Klasyczna klasa problemów polega na tym, że aplikacja oczekuje zwykłego pliku, a dostaje FIFO, device node albo inny obiekt specjalny. Jeżeli programista może egzekwować typ obiektu na poziomie syscalla, zmniejsza się powierzchnia błędów typu TOCTOU i niespodziewanych przekierowań.
Nowy target dm-inlinecrypt w device-mapperze to kolejna zmiana z obszaru infrastruktury. Ma wspierać inline block-device encryption i jest opisywany jako praktyczny zamiennik dla dm-crypt w scenariuszach, w których sprzętowa ścieżka szyfrowania blokowego jest właściwym wyborem. Dla administratora oznacza to konieczność śledzenia, kiedy dystrybucje oraz narzędzia instalacyjne zaczną wystawiać tę funkcję w stabilny, wspierany sposób. Sam fakt obecności w mainline nie znaczy jeszcze, że dana platforma enterprise natychmiast da na to wsparcie SLA.
Sprzęt: AMD, Intel, Apple M3 i Linux na nowych platformach
Linux 7.2 jest mocny również po stronie enablementu sprzętowego. W sterowniku amdgpu pojawiło się początkowe wsparcie HDMI 2.1 FRL, ważne dla konfiguracji o wysokiej rozdzielczości i wysokim odświeżaniu. To temat szczególnie istotny dla użytkowników Radeonów, monitorów 4K/120 Hz, telewizorów HDMI 2.1 oraz stacji roboczych używanych także do grafiki lub wideo.
W tej wersji pojawia się także sterownik AMD ISP4. ISP, czyli Image Signal Processor, odpowiada za przetwarzanie danych z kamer w części nowszych laptopów. Gdy taki komponent trafia do mainline, dystrybucje mają mniejszą potrzebę utrzymywania vendorowych patchy, a użytkownik ma większą szansę, że kamera w notebooku zadziała po instalacji zwykłego kernela dystrybucyjnego.
Po stronie Apple Silicon Linux 7.2 jest etapem, w którym mainline może startować na sprzęcie Apple M3. To nie oznacza kompletnego, wygładzonego wsparcia wszystkich funkcji laptopa lub stacji Apple, ale jest ważnym kamieniem milowym dla projektów, które pracują nad Linuksem na ARM-owych komputerach Apple. Z kolei w świecie Intel i RISC-V mamy typowy dla kernela zestaw przygotowań pod nowe platformy, sterowniki i usprawnienia wirtualizacyjne.
Dlaczego nie instalować odruchowo na produkcji
W komunikacie wydania z 16 sierpnia 2026 r. Torvalds zwrócił uwagę, że ostatni tydzień przed finalnym wydaniem był większy, niż by chciał, a w drzewie znalazły się późne reverty, szczególnie wokół DRM scheduling. To nie jest powód do paniki, lecz przypomnienie, że mainline kernel jest miejscem aktywnego rozwoju. Kernel 7.2.2 z 28 sierpnia 2026 r. zawiera już poprawki stabilizacyjne, ale organizacje używające Ubuntu LTS, Debiana stable, RHEL, SLES czy dystrybucji appliance’owych zwykle powinny czekać na kernel przygotowany i wspierany przez własnego vendora.
Największe praktyczne ryzyka przy samodzielnej migracji to:
- niezgodność modułów DKMS, na przykład sterowników NVIDIA, modułów Wi-Fi, ZFS albo komponentów hypervisora;
- problemy z Secure Boot, jeżeli kernel nie jest podpisany kluczem zaufanym dla danej maszyny;
- zmiana zachowania schedulerów CPU/GPU pod obciążeniem, której nie widać w krótkim teście;
- regresje w sterownikach storage, sieci albo grafiki specyficzne dla konkretnego modelu sprzętu;
- brak wsparcia producenta dystrybucji po instalacji kernela spoza oficjalnego repozytorium.
Praktyczny plan testów dla administratora
Najrozsądniejszy scenariusz to potraktowanie Linuksa 7.2 jako kandydata do laboratorium lub canary rollout. Najpierw trzeba zinwentaryzować obecny kernel, moduły zewnętrzne i profil obciążenia. Następnie wybrać jedną lub kilka maszyn, które są podobne do produkcji, ale możliwe do szybkiego odtworzenia. Test powinien mierzyć zachowanie aplikacji, a nie tylko syntetyczne parametry systemu.
# Inwentaryzacja przed testem kernela
uname -a
cat /etc/os-release
lsmod | sort > lsmod-przed.txt
dkms status || true
findmnt -t btrfs,ext4,xfs
swapon --show
lscpu
numactl --hardware 2>/dev/null || true
# Podstawowe obserwacje po starcie na nowym kernelu
uname -r
journalctl -k -b --no-pager | grep -Ei 'error|warn|fail|taint|drm|amdgpu|nvme|btrfs|xfs|ext4'
cat /proc/filesystems
cat /proc/interrupts | head -40W środowisku serwerowym do testu warto dodać metryki z Prometheusa, eBPF albo perf: context switches, migracje zadań, wykorzystanie CPU per NUMA node, opóźnienia I/O, major/minor page faults, PSI dla CPU/memory/I/O oraz p95/p99 czasu odpowiedzi aplikacji. Przy Btrfs sensowne są testy snapshotów, scrub, send/receive, direct I/O i zachowanie pod zapełnionym wolumenem. Przy laptopach i stacjach roboczych trzeba sprawdzić suspend/resume, kamerę, HDMI/DisplayPort, dźwięk, Bluetooth i Wi-Fi.
Jeżeli używasz kontenerów, test powinien objąć także runtime: containerd, Docker, CRI-O, overlayfs, limity cgroup v2, AppArmor/SELinux oraz profile seccomp. Kernel jest wspólną warstwą izolacji dla wszystkich kontenerów na hoście, więc nawet pozornie niewielka zmiana w filesystemie, sieci lub pamięci może wpłynąć na wiele workloadów naraz.
Kiedy Linux 7.2 ma sens
Najmocniejszy argument za szybkim testowaniem Linuksa 7.2 mają zespoły obsługujące nowy sprzęt: najnowsze laptopy AMD, stacje z Radeonami i ekranami HDMI 2.1, maszyny testowe z Apple M3, platformy RISC-V, serwery z nowymi procesorami i środowiska, które mogą skorzystać z lepszej lokalności cache. Druga grupa to administratorzy wydajnościowi, którzy potrafią porównać kernel w powtarzalnych warunkach i mają konkretne hipotezy: mniej refaultów, lepsze p99, mniejszy narzut swapu albo wyższy throughput przy tym samym limicie CPU.
Jeżeli natomiast utrzymujesz stabilne systemy produkcyjne bez problemów sprzętowych, używasz kernela LTS z backportami bezpieczeństwa i nie masz czasu na pełne testy regresji, Linux 7.2 powinien poczekać na kanał dystrybucyjny. Kernel.org jasno rozróżnia mainline, stable i longterm: mainline przynosi nowe funkcje, stable dostaje poprawki dla danej gałęzi, a longterm jest podstawą długiego utrzymania.
Podsumowanie praktyczne
Linux 7.2 to wydanie warte uwagi, bo dotyka realnych obszarów pracy administratora: schedulingu, pamięci, swapu, Btrfs, szyfrowania blokowego, transferu danych po USB4 i obsługi nowego sprzętu. Nie jest to jednak kernel do bezrefleksyjnej instalacji na produkcji. Najlepszy ruch na 31 sierpnia 2026 r. to przygotować małe środowisko testowe, porównać 7.2.2 z kernelem używanym w organizacji, sprawdzić DKMS i Secure Boot, a decyzję o wdrożeniu oprzeć na metrykach aplikacji, nie na samym numerze wersji.
