Novità del kernel Linux 7.2 per un VPS

Novità del kernel Linux 7.2

Il kernel Linux 7.2 è stato rilasciato il 16 agosto 2026. La modifica più importante è la pianificazione consapevole della cache, implementata dietro la nuova opzione CONFIG_SCHED_CACHE. Lo scheduler ora cerca di mantenere i thread di uno stesso processo su CPU che condividono la stessa cache di ultimo livello (LLC). Il resto della release non modifica il modo in cui il carico di lavoro viene assegnato a una CPU.

Il resto di 7.2, in sintesi: una revisione del percorso di fast commit di ext4, miglioramenti a MGLRU (il codice di recupero della memoria least recently used multi-generazionale), un nuovo target device mapper dm-inlinecrypt per la cifratura inline dei dispositivi a blocchi e la rimozione dell’ultima chiamata strncpy() dal codice sorgente del kernel.

Un solo fatto determina se la funzionalità principale può essere utile nel tuo caso, quindi lo esaminiamo per primo. Il bilanciamento del carico consapevole della cache si attiva soltanto quando un nodo NUMA (non-uniform memory access) contiene più di una LLC. In genere un guest VPS non espone questa topologia. Nella maggior parte dei guest, quindi, il codice viene incluso nella compilazione ma non viene mai attivato. Per verificarlo bastano due comandi, nella sezione "Un guest VPS vede qualcosa di tutto questo?" più avanti.

Ogni affermazione tecnica in questa pagina proviene dal changelog della versione 7.2 e dalla stessa serie di patch sulla pianificazione consapevole della cache, consultati il 18 agosto 2026. Le fonti sono elencate verso la fine, così puoi confrontarle con il comportamento del tuo kernel.

Perché lo scheduler dove conoscere le cache

Un socket server moderno non ha un'unica cache di ultimo livello. Un package AMD EPYC è composto da diversi core complex e ogni complex dispone della propria cache L3. Anche i recenti processori Intel Xeon suddividono un socket in più domini di cache. Di conseguenza, un singolo nodo NUMA può contenere quattro, otto o più LLC separate e due thread dello stesso programma possono finire in cache diverse.

Questa collocazione comporta un costo in termini di tempo. Quando due thread condividono una pagina proveniente da LLC diverse, ogni cache mantiene una propria copia della linea. Una scrittura su un lato invalida la copia sull'altro lato, quindi la lettura successiva deve attraversare l'interconnessione oppure accedere alla memoria principale. Questo fenomeno è chiamato cache bouncing. Si manifesta come cicli trascorsi in attesa, non come tempo di inattività della CPU. Per questo è facile non rilevarlo osservando il load average.

Prima della 7.2 il load balancer collocava i task in base al carico, all'utilizzo e alle CPU inattive. Non disponeva di informazioni che indicassero che "questi due task leggono la stessa memoria". La 7.2 ne aggiunge una, usando un'approssimazione che non ha costi di calcolo: i thread di un processo condividono lo stesso spazio di indirizzamento, quindi è ragionevole considerarli potenzialmente condivisori degli stessi dati.

Come il kernel sceglie la LLC preferita

Il tracciamento è associato al processo, in mm_struct, la struttura del kernel che rappresenta uno spazio degli indirizzi. Il kernel campiona periodicamente dove vengono eseguiti i thread del processo e conta, per ogni LLC, quanta parte del processo si trova in ciascuna di esse. La LLC che contiene la quantità maggiore diventa la LLC preferita per l'intero processo. Le decisioni successive leggono questo singolo valore.

Il valore viene utilizzato in due percorsi. Al risveglio, lo scheduler orienta la scelta della CPU verso la LLC preferita dal processo, invece di selezionare una CPU inattiva qualsiasi del nodo. Durante il bilanciamento del carico, quando i task devono essere spostati tra gruppi di scheduler, il kernel preferisce spostare i task che preferiscono già la LLC di destinazione ed evita di allontanare un task dalla LLC che preferisce.

I meccanismi di protezione sono importanti quanto la funzionalità, perché concentrare tutti i thread di un processo molto attivo in un unico dominio di cache può sovraccaricare quel dominio mentre il resto del socket rimane inattivo. I parametri regolabili si trovano in debugfs, il filesystem di debug del kernel, sotto /sys/kernel/debug/sched/:

• llc_aggr_tolerance, un valore da 0 a 100, determina con quale intensità il kernel aggrega i task. 0 disattiva lo scheduling consapevole della cache durante l'esecuzione. 1 è l'impostazione prudente: un processo il cui RSS (resident set size, ovvero la memoria residente) è maggiore della LLC, oppure che esegue più thread dei core disponibili nella LLC, non viene spostato. 100 esegue l'aggregazione indipendentemente dalle dimensioni o dal numero di thread.
• llc_overload_pct, con valore predefinito 50, è l'utilizzo medio oltre il quale i conteggi della LLC preferita vengono considerati occupati.
• llc_imb_pct, con valore predefinito 20, limita lo squilibrio che una migrazione con aggregazione può creare quando la LLC preferita supera quella soglia di sovraccarico.
• llc_epoch_period, con valore predefinito 10 ms, indica la frequenza con cui viene raccolta l'occupazione.
• llc_epoch_affinity_timeout, con valore predefinito 50 ms, indica per quanto tempo un processo inattivo conserva la propria preferenza prima che il kernel la elimini.

Leggere i valori in uso prima di modificarli, perché una distribuzione può fornire valori predefiniti diversi: sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance.

Quali carichi di lavoro possono trarne vantaggio e quali no

I numeri riportati di seguito sono quelli pubblicati insieme alla serie di patch. Sono stati misurati su hardware di classe server e, in alcuni casi, con il parametro di tolleranza impostato su un valore aggressivo. Considerateli come lo scenario favorevole su bare metal, non come una promessa per il vostro sistema.

[
  {
    "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 con un singolo gruppo è migliorato del 30.57%, mentre il test di throughput di ChaCha20 su AMD Genoa è migliorato del 44%. Tutti i 3 risultati sono stati ottenuti su hardware server con più LLC, interamente sotto il controllo del tester.

Un carico di lavoro che può trarne vantaggio presenta caratteristiche simili:

• Più thread nello stesso processo, così da avere thread da raggruppare.
• Condivisione effettiva tra questi thread, quindi il costo di una cache line trasferita è realmente presente.
• Un working set che rientra in una sola LLC, perché non è possibile ottenere località nella cache spostando un processo più grande della cache.
• Capacità disponibile sulla macchina, così lo scheduler può scegliere realmente dove collocare il thread successivo.

Nei casi seguenti, invece, non c'è alcun vantaggio:

• Una macchina già a pieno carico. Tutte le CPU sono occupate, quindi il posizionamento è obbligato e i vantaggi riportati si riducono.
• Processi a thread singolo e pool di processi indipendenti che non condividono dati.
• Un working set molto più grande della LLC, che l'impostazione prudente llc_aggr_tolerance esclude intenzionalmente.
• Un nodo che segnala una sola LLC, dove la funzionalità non viene mai attivata.

Esiste anche un costo, e la serie di patch lo dichiara esplicitamente. La raccolta dei dati sull'occupazione viene eseguita nel contesto del task. In alcuni test questo ha aumentato la latenza delle richieste, perché tale attività ritardava il ritorno del task nello spazio utente. L'aggregazione può inoltre aumentare la variabilità della latenza anche quando il throughput medio migliora. Se vi interessa la latenza di coda più della media, misurate la vostra latenza di coda.

Un guest VPS vede qualcosa di tutto questo

La risposta dipende da due fattori.

Primo: la funzionalità è condizionata dalla topologia. Il bilanciamento del carico consapevole della cache viene abilitato solo quando all'interno di un nodo NUMA esistono più LLC; il kernel registra questa condizione durante la configurazione della topologia. Se un nodo espone una sola LLC, il percorso consapevole della cache resta inattivo, indipendentemente dal valore dei tunable.

Secondo: la topologia della cache letta dal guest non è quella dell'host. È quella presentata dal modello CPU dell'hypervisor. In genere un guest KVM (kernel based virtual machine) non riceve la reale struttura L3 dell'host; di conseguenza ragiona su una rappresentazione semplificata.

Verifica cosa vede il tuo guest:

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

index3 è la cache L3 sulla maggior parte delle CPU x86. Una sola riga che elenca tutte le vCPU indica che il guest vede una singola LLC, quindi la funzionalità non ha nulla da organizzare. No such file or directory indica che al guest non è stata esposta alcuna cache L3; il guest considera quindi come ultimo livello una cache di livello inferiore, con confini inventati dall'hypervisor anziché determinati dal silicio.

Esiste poi la doppia schedulazione, che rappresenta la reale limitazione per qualsiasi tenant. Il kernel del guest assegna i thread alle vCPU. Il kernel dell'host assegna i thread delle vCPU ai core fisici. Un guest che raggruppa con attenzione quattro thread sulle vCPU da 0 a 3 esprime una preferenza relativa a quattro thread dell'host; l'host può assegnarli a domini di cache fisici diversi e spostarli in seguito. La decisione del guest non è errata, ma non è quella definitiva. È lo stesso confine tra livelli che produce lo steal time lasciato sulle tue vCPU da un vicino rumoroso.

In che modo questa funzionalità è quindi rilevante per un tenant VPS? In due casi. Nei piani in cui la topologia è reale anziché sintetica, ad esempio con core dedicati o istanze più grandi che espongono una topologia pass-through, lo scheduler del guest prende una decisione relativa a hardware effettivamente presente. Inoltre, sul kernel dell'host del provider, il posizionamento consapevole della cache dei thread delle tue vCPU rappresenta un vantaggio che può sfruttare il provider, non tu. La disposizione della cache varia anche in base all'architettura, aggiungendo un'ulteriore variabile nel confronto tra un VPS Arm e un VPS x86.

Misurare il comportamento della cache all'interno di un guest è più difficile che su hardware fisico. perf stat -e cache-misses spesso restituisce <not supported> perché l'hypervisor non espone il PMU (performance monitoring unit) ai guest. Misura invece throughput e latenza della tua applicazione e usa il parametro di debugfs come interruttore tra le due esecuzioni.

Verificare se il kernel dispone di 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 indica che il kernel è stato compilato con questa opzione. Una riga # CONFIG_SCHED_CACHE is not set indica che l'opzione esiste in quella versione, ma che la distribuzione l'ha disabilitata. Nessun output indica in genere che il kernel è precedente all'introduzione dell'opzione; uname -r lo conferma. Alcune immagini cloud minimali non includono il file /boot/config-*. In questo caso leggere zcat /proc/config.gz, che funziona solo se il kernel è stato compilato con CONFIG_IKCONFIG_PROC.

La riga ls mostra i parametri llc_* quando la funzionalità è inclusa nel kernel. Se non restituisce output mentre è presente CONFIG_SCHED_CACHE=y, montare prima debugfs con sudo mount -t debugfs none /sys/kernel/debug.

Per confrontare il carico di lavoro con la funzionalità attivata e disattivata, registrare prima il valore corrente, perché sarà necessario ripristinarlo:

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

Eseguire il benchmark, riscrivere il valore annotato e ripetere il test. Le modifiche eseguite tramite debugfs non persistono dopo un riavvio, come richiesto durante i test.

Quando una distribuzione includerà il kernel 7.2

Il kernel mainline non è quello avviato dal tuo VPS. La versione in uname -r proviene dalla tua distribuzione, e ogni distribuzione segue un percorso diverso per portare una release mainline sul server.

Fedora aggiorna le release stabili a nuovi kernel mainline durante il periodo di supporto. Per questo, su Fedora, sudo dnf upgrade --refresh seguito da un riavvio è l'intera procedura. Di solito è anche il primo ambiente in cui un tenant può provare un nuovo kernel. Questa cadenza fa parte delle caratteristiche della scelta Fedora Server su un VPS.

Ubuntu distribuisce un nuovo kernel con ogni release semestrale, quindi lo rende disponibile anche per la precedente release a supporto esteso (LTS) tramite lo stack HWE (hardware enablement). Ad agosto 2026, Ubuntu 24.04 LTS installa ancora il kernel GA 6.8, rilasciato ad aprile 2024, mentre lo stack HWE è passato alla versione 6.14 ad agosto 2025 e alla versione 6.17 a febbraio 2026. Questa è la tempistica realistica: una release mainline di agosto 2026 raggiunge lo stack HWE di una LTS circa un anno dopo.

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

Debian stable mantiene un kernel per tutta la durata della release e offre versioni più recenti tramite backports, che abiliti per singolo pacchetto:

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

Dopo una di queste procedure, riavvia e verifica con uname -r e con il grep precedente. Un nuovo kernel non può essere caricato dinamicamente: il live kernel patching su un VPS sostituisce il codice di singole funzioni nel kernel in esecuzione, ma non può modificare i layout delle strutture né aggiungere file debugfs. La pianificazione consapevole della cache fa entrambe le cose, perché aggiunge campi a mm_struct, quindi può essere inclusa solo avviando un nuovo kernel.

Ci sono due attività pratiche successive. Mantieni avviabile il kernel precedente finché il nuovo kernel non avrà gestito il tuo carico per un periodo sufficiente. A questo serve impostare quale kernel viene avviato su un VPS. Inoltre, controlla /boot, perché la partizione di boot di un VPS di piccole dimensioni può esaurire lo spazio dopo alcuni aggiornamenti del kernel, come descritto in rimuovere i kernel precedenti su Ubuntu.

Un ultimo aspetto riguarda la responsabilità operativa. Su un VPS KVM, il kernel guest è sotto il tuo controllo: lo scegli, lo avvii e puoi ripristinare la versione precedente. Il kernel dell'host appartiene al provider, e nessuna impostazione all'interno del guest modifica lo scheduler eseguito dall'hypervisor. Per un tenant, quindi, una nota di rilascio sul posizionamento dello scheduler descrive solo metà del quadro. L'altra metà, quella che puoi controllare, riguarda il guest.

Fonti utilizzate per questa pagina

• Il riepilogo delle modifiche della versione 7.2 su kernelnewbies.org, per la data di rilascio del 16 agosto 2026 e per le modifiche non relative allo scheduler.
• La copertura di LWN sulla serie relativa allo scheduling consapevole della cache, disponibile su lwn.net/Articles/1041668 e lwn.net/Articles/1058288, per i parametri regolabili tramite debugfs, il meccanismo di preferenza per processo e i valori dei benchmark riportati.
• La patch che abilita la funzionalità in base alla topologia, "sched/cache: Introduce sched_cache_present", per la regola secondo cui il bilanciamento del carico consapevole della cache richiede più di una LLC in un nodo NUMA.

Per la versione precedente, vedere cosa è cambiato nel kernel Linux 7.1. Per informazioni sull'origine dei numeri di versione, vedere la cronologia del kernel Linux.

FAQ

La pianificazione consapevole della cache in Linux 7.2 rende più veloce una VPS?

Di solito no, non da sola. La funzionalità si attiva soltanto quando un nodo NUMA segnala più di una cache di ultimo livello. Una tipica macchina virtuale KVM non espone questa topologia, quindi il codice non viene mai eseguito. Quando invece la funzionalità è attiva, la macchina virtuale viene comunque pianificata due volte: il kernel guest seleziona una vCPU e il kernel dell'host decide su quale core fisico eseguire il relativo thread della vCPU. Di conseguenza, la scelta della cache effettuata dal guest può essere annullata dall'host. Esegui cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u nel guest. Una sola riga che include tutte le vCPU indica che non c'è nulla da organizzare per la funzionalità.

Come verifico se il mio kernel dispone di CONFIG_SCHED_CACHE?

Esegui grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r). CONFIG_SCHED_CACHE=y indica che è integrata nel kernel, # CONFIG_SCHED_CACHE is not set indica che la distribuzione l'ha disabilitata e nessun output indica che il kernel è precedente all'opzione. Se l'immagine non contiene il file /boot/config-*, prova zcat /proc/config.gz, che esiste soltanto nei kernel compilati con CONFIG_IKCONFIG_PROC. Puoi verificare la funzionalità a runtime con sudo ls /sys/kernel/debug/sched/ | grep -i llc, che elenca i parametri llc_* quando la funzionalità è presente.

Come disattivo la pianificazione consapevole della cache senza riavviare?

Scrivi 0 nel parametro di tolleranza: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. Questo disabilita la funzionalità a runtime e fornisce un interruttore A/B pulito per un benchmark. Leggi prima il valore corrente con sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance e ripristinalo dopo, perché i valori predefiniti variano tra le build. Nessun valore scritto in debugfs sopravvive a un riavvio. Se cat restituisce No such file or directory, il kernel non include la funzionalità in fase di compilazione e non c'è nulla da disattivare.

Quando Ubuntu o Debian distribuiranno un kernel basato sulla versione 7.2?

Fedora riallinea le release stabili ai nuovi kernel mainline, quindi la versione arriva prima tramite un normale dnf upgrade e un riavvio. Ubuntu distribuisce nuovi kernel con ogni release semestrale e li rende disponibili anche per la LTS precedente tramite lo stack HWE. Storicamente, il ritardo è vicino a un anno: ad agosto 2026, lo stack HWE di Ubuntu 24.04 LTS usa la versione 6.17, rilasciata a febbraio 2026, mentre il kernel GA è ancora la versione 6.8. Debian stable mantiene un kernel per tutta la release e offre versioni più recenti tramite trixie-backports, che si installano per pacchetto con apt install -t trixie-backports linux-image-amd64.