Scheduler Linux e gaming su vecchi PC: le patch che cambiano tutto

Un Intel Core i7-2600K del 2011, una Radeon RX 580 e un gioco Windows eseguito tramite Proton: sembra lo scenario peggiore per parlare di ottimizzazioni gaming su Linux. Eppure è esattamente da questa macchina — chiamata ironicamente “potato” — che arrivano i risultati più interessanti del lavoro attuale di Peter Zijlstra, ingegnere Intel e sviluppatore storico dello scheduler Linux. Le sue patch in corso, battezzate “sched: Flatten the pick”, affrontano un problema noto da tempo nel kernel: la gestione inefficiente dei cgroup sotto carico CPU elevato. I numeri registrati con MangoHUD parlano chiaro: fps minimi da 3,8 a 20,6, frame time medio dimezzato.

Indice

1. Cosa sono i cgroup e perché impattano il gaming
2. Il problema del weight fragmentation nello scheduler CFS
3. L’esperimento: dati benchmark con MangoHUD
4. Perché l’hardware vecchio mostra differenze così evidenti
5. Quando arriveranno nel kernel ufficiale?
6. FAQ

Cosa sono i cgroup e perché impattano il gaming

I cgroup (control groups) sono un meccanismo del kernel Linux che permette di suddividere le risorse di sistema — CPU, memoria, I/O — tra gruppi di processi distinti. Ogni container Docker, ogni sandbox Flatpak, ogni sessione systemd e perfino Steam quando avvia un gioco finisce per operare all’interno di uno o più cgroup.

Il problema per il gaming non è l’esistenza dei cgroup in sé, ma come lo scheduler CFS (Completely Fair Scheduler) distribuisce il peso computazionale tra i vari livelli della gerarchia. In una sessione gaming tipica su Linux coesistono decine di processi attivi: il gioco stesso, Steam Runtime, Proton con Wine, PipeWire per l’audio, compositori Wayland, notifiche di sistema. Tutti competono per lo stesso pool di risorse CPU attraverso strutture cgroup annidate.

Come ha documentato Zijlstra nella mailing list ufficiale del kernel, la formula attuale dello scheduler disperde il peso totale di un task group su tutti i core disponibili. Su una CPU a 64 core, questo significa che un cgroup finisce con una priorità equivalente a quella di un processo nice 19 — cioè la priorità più bassa possibile — per ogni singolo core. Su macchine server con 256 thread logici, il margine diventa ancora più esiguo. Il risultato pratico è che i processi interattivi, quelli che devono ricevere tempo CPU in modo rapido e prevedibile, vengono trattati dallo scheduler come task di bassa priorità nonostante il loro ruolo critico.

Se vuoi approfondire la gestione delle risorse di sistema su Linux, puoi leggere la nostra guida su come creare un Linux persistente su chiavetta USB.

Il problema del weight fragmentation nello scheduler CFS

Il patch series “sched: Flatten the pick” di Zijlstra interviene su due aspetti correlati dello scheduler:

1. Weight fragmentation nei cgroup
Quando lo scheduler distribuisce il peso di un task group tra i core disponibili, utilizza una formula che divide il peso totale per il numero di CPU. Il risultato è che, in scenari di saturazione, gruppi di processi importanti — come un gioco in esecuzione — ricevono una priorità sproporzionatamente bassa. La patch proposta corregge questo comportamento riparametrizzando come viene calcolato e distribuito il peso per cgroup.

2. Selezione gerarchica del task successivo
Il meccanismo attuale di scelta del prossimo task da eseguire deve attraversare molteplici livelli della gerarchia dei cgroup. La patch collassa questa navigazione in un unico livello, riducendo la latenza nella selezione del task. In un contesto gaming, dove lo scheduler deve fare queste decisioni migliaia di volte al secondo, anche una riduzione minima della latenza per ogni selezione si traduce in frame time più stabili.

Zijlstra ha anche sperimentato una riduzione aggressiva della time slice — l’intervallo di tempo massimo assegnato a ogni processo prima che lo scheduler intervenga — portandola a un decimo del valore base tramite chrt. L’effetto è uno scheduler più reattivo che cede il controllo della CPU più frequentemente, permettendo ai processi interattivi di ottenere il loro turno con latenza inferiore.

Per un confronto con l’approccio di Microsoft alla stessa problematica, abbiamo analizzato il Windows 11 Low Latency Profile e le sue implicazioni per la reattività del sistema.

L’esperimento: dati benchmark con MangoHUD

Zijlstra ha costruito un test volutamente estremo ma realistico. La configurazione: Intel Core i7-2600K (Sandy Bridge, 2011), Radeon RX 580 (architettura Polaris), gioco “Shadows: Awakening” via Lutris con GE-Proton10-34 e Steam Runtime 3 “sniper”. Per simulare un sistema sotto pressione — browser con molte schede, Discord, servizi in background — ha avviato 8 processi spin.sh in parallelo, uno per ogni thread logico della CPU, con priorità ridotta tramite nice.

I risultati registrati con MangoHUD sono netti:

Il dato più significativo non riguarda gli fps medi, ma i picchi di frame time. Un frame time superiore a 100 ms produce micro-blocchi chiaramente percepibili a occhio nudo, indipendentemente dalla fluidità media della sessione. Abbattere quel valore a 37 ms cambia completamente la sensazione soggettiva del gameplay.

Vale la pena precisare che, come Zijlstra ha specificato nella sua comunicazione, il test non confronta direttamente il kernel con e senza le patch attive, ma valuta l’impatto della riduzione della time slice su un kernel con la patch. L’esperimento era finalizzato a verificare il comportamento dello scheduler sotto carichi non banali, non a produrre un benchmark comparativo definitivo.

Perché l’hardware vecchio mostra differenze così evidenti

Le CPU Sandy Bridge come il Core i7-2600K dispongono di 4 core fisici con Hyper-Threading per un totale di 8 thread logici. In condizioni di saturazione, la competizione tra thread diventa immediata e le inefficienze dello scheduler emergono senza margini di potenza bruta a nasconderle. Le CPU moderne con 12 o 16 core hanno abbastanza risorse di riserva da mascherare lo stesso problema.

La Radeon RX 580 completa il quadro: l’architettura Polaris riceve ancora supporto solido dai driver open source AMDGPU e RADV, quindi il collo di bottiglia in questo scenario è esclusivamente legato alla gestione CPU, non ai driver grafici. Questo rende il test più interpretabile.

Un punto emerso dalla discussione tecnica è rilevante: il problema del weight fragmentation peggiora all’aumentare del numero di core. Su una CPU consumer con 16 core e 32 thread, la frammentazione del peso nei cgroup può diventare altrettanto problematica di quanto osservato sul Sandy Bridge in saturazione. L’hardware datato rende il difetto visibile, ma il difetto esiste indipendentemente dall’età della CPU.

Quando arriveranno nel kernel ufficiale?

Le patch “sched: Flatten the pick” sono alla seconda versione (v2) e disponibili sulla mailing list ufficiale del kernel Linux (lore.kernel.org). Non sono ancora state accettate nel ramo principale (mainline) del kernel.

Il processo standard prevede revisione da parte dei maintainer dello scheduler, possibili ulteriori iterazioni, e infine merge in una kernel release. Una volta nel mainline, i benefici saranno disponibili per tutte le distribuzioni che aggiornano il kernel — incluse le gaming-first come Bazzite e CachyOS, che tendono a integrare patch sperimentali anche prima del merge ufficiale.

FAQ — Domande Frequenti

Come funziona lo scheduler Linux per il gaming?
Lo scheduler Linux CFS (Completely Fair Scheduler) distribuisce il tempo CPU tra tutti i processi cercando equità. Per il gaming, l’equità non è l’obiettivo ideale: i processi di gioco richiedono accesso rapido e prevedibile alla CPU. Le patch di Zijlstra intervengono sulla gestione dei cgroup per ridurre la latenza nella selezione del task successivo, migliorando la stabilità del frame time nelle sessioni più intensive.

Cosa sono i cgroup Linux e cosa c’entrano con il gaming?
I cgroup (control groups) sono il meccanismo del kernel con cui Linux raggruppa i processi e assegna loro quote di risorse. Steam, Proton, Wine e i servizi di sistema operano attraverso strutture cgroup. Quando questi gruppi vengono gestiti male dallo scheduler, i processi interattivi come un gioco subiscono picchi di frame time elevati durante i momenti di saturazione CPU.

Le patch “sched: Flatten the pick” migliorano anche le CPU moderne?
Sì. Il problema del weight fragmentation nei cgroup peggiora all’aumentare del numero di core. Su una CPU desktop con 16 o 32 core, la formula attuale può frammentare il peso dei task group in modo ancora più problematico rispetto a un Sandy Bridge a 8 thread. L’hardware vecchio rende il difetto visibile, ma il problema è strutturale nel kernel attuale e non dipende dall’età della CPU.

Quando le patch di Zijlstra arriveranno nel kernel Linux ufficiale?
Le patch sono alla versione 2 e sono in revisione sulla mailing list del kernel. Non esiste una data di rilascio ufficiale. Il merge nel ramo mainline dipende dall’iter di revisione dei maintainer. Distribuzioni gaming-first come Bazzite e CachyOS potrebbero includerle prima del merge ufficiale come patch out-of-tree.

Posso applicare oggi le patch dello scheduler Linux per il gaming?
Non tramite aggiornamento standard: le patch non sono ancora nel kernel mainline. È possibile compilare un kernel custom applicando le patch dalla mailing list, ma si tratta di una procedura avanzata. La soluzione più immediata è usare distribuzioni con scheduler ottimizzati out-of-tree, come CachyOS (scheduler BORE) o Bazzite.

Lo scheduler Linux stava penalizzando il gaming su hardware multi-core senza che quasi nessuno se ne accorgesse. Le patch di Zijlstra portano alla luce un problema strutturale nel kernel che impatta non solo le macchine datate, ma potenzialmente qualsiasi sistema Linux con carico CPU elevato. Hai mai testato gaming su Linux con hardware datato? Raccontamelo nei commenti.

#tuttelevitediunmaker