Linux migliora il gaming sui vecchi PC grazie allo scheduler

Un chip Intel Core i7-2600K del 2011, una Radeon RX 580 basata su architettura Polaris e un gioco Windows eseguito su Linux tramite Proton: non sembra il punto di partenza ideale per parlare di ottimizzazioni. Eppure è proprio da una macchina definita ironicamente “potato” che arrivano alcuni dei risultati più interessanti emersi in questi giorni dal lavoro di Peter Zijlstra, storico sviluppatore del kernel Linux, ingegnere Intel e figura centrale nello sviluppo dello scheduler.

Il tema tocca un’area delicata del kernel: la gestione della schedulazione dei processi nei cgroup. Si tratta del meccanismo che Linux usa per suddividere risorse CPU, memoria e I/O tra gruppi di processi diversi: container, sandbox, desktop environment, servizi systemd e perfino alcune sessioni gaming sotto Steam finiscono inevitabilmente per passare da qui.

Negli anni Linux ha costruito un sistema estremamente flessibile. Il problema è che la complessità dello scheduler è cresciuta parecchio con l’aumento del numero di core e thread disponibili: oggi non è raro trovare CPU desktop da 16 o 24 core e server con oltre 256 thread logici. Secondo Zijlstra, parte dell’algoritmo attuale disperde il peso dei task tra i vari core in modo inefficiente, con effetti collaterali evidenti soprattutto nei carichi interattivi come il gaming.

Perché il gaming soffre quando la CPU è sotto pressione

Un gioco moderno non richiede soltanto fps elevati: conta soprattutto la regolarità del frame pacing, cioè il tempo necessario per produrre ogni fotogramma. Se il kernel distribuisce in modo errato il tempo di elaborazione della CPU tra i processi, le conseguenze non si limitano a una riduzione del frame rate medio: possono verificarsi scatti evidenti nelle animazioni, blocchi improvvisi del sistema e tempi di rendering dei fotogrammi irregolari e difficili da gestire.

Zijlstra ha deciso di verificare il comportamento del kernel in una situazione volutamente estrema ma molto realistica. Ha eseguito “Shadows: Awakening” tramite Lutris, usando GE-Proton10-34 e Steam Runtime 3 “sniper“. In parallelo ha avviato 8 processi chiamati spin.sh, impostati con priorità ridotta tramite il parametro nice del sistema Linux, uno per ogni thread disponibile sulla CPU Sandy Bridge.

I processi spin.sh sono script creati per eseguire continuamente operazioni cicliche, mantenendo occupata la CPU senza svolgere attività realmente utili. Il nome spin richiama infatti il concetto di busy spinning, cioè un processo che resta attivo in un ciclo infinito consumando risorse del processore.

La macchina si trovava costantemente sotto pressione CPU, con una situazione simile a quella che può verificarsi facilmente anche su desktop moderni: browser con molte schede aperte, Discord, streaming, compilazioni in background, launcher e telemetria varia.

Il risultato iniziale è stato pessimo. Il gioco diventava quasi inutilizzabile nonostante la RX 580 sia ancora sufficiente per il Full HD in diversi titoli DirectX 11 tradotti tramite Vulkan.

La modifica alle time slice dello scheduler Linux

La parte interessante arriva dopo. Zijlstra ha ridotto drasticamente la dimensione della time slice assegnata dallo scheduler, portandola a un decimo del valore base. L’obiettivo era verificare se una distribuzione più aggressiva del tempo CPU potesse migliorare la responsività generale della macchina.

I numeri raccolti tramite MangoHUD mostrano differenze evidenti: gli fps minimi sono passati da 3,8 a 20,6; il frame time massimo è sceso da 107,4 ms a 37,2 ms. Ancora più importante il frame time medio: da 34,5 ms a 19,5 ms.

Il valore relativo agli fps medi, da solo, racconta poco: il salto più significativo riguarda la stabilità dell’esperienza. Un frame time superiore a 100 ms produce micro blocchi chiaramente percepibili anche da utenti non esperti: ridurre quei picchi cambia completamente la sensazione durante il gameplay.

Quelle congegnate da Zijlstra non sono ancora patch definitive pronte per il merge nel ramo principale del kernel Linux. Il lavoro fa parte di una revisione che certamente arriverà a maturazione in tempi ragionevoli.

Perché l’hardware vecchio mostra differenze così evidenti

Le CPU Sandy Bridge come il Core i7-2600K hanno un comportamento molto diverso rispetto ai processori recenti. Mancano molte ottimizzazioni introdotte negli anni: scheduler hardware più sofisticati, cache più ampie, meccanismi avanzati di power management e gestione delle latenze.

Inoltre il 2600K dispone di 4 core fisici con Hyper-Threading, per un totale di 8 thread logici: in scenari di saturazione, la competizione tra thread diventa aggressiva e le inefficienze dello scheduler emergono immediatamente.

Proprio l’hardware vecchio rende più visibili alcuni limiti del kernel moderno: su CPU contemporanee con frequenze elevate e molte risorse disponibili, parte del problema resta nascosto dalla potenza bruta.

La Radeon RX 580 contribuisce poi a creare un caso d’uso interessante. Polaris continua a ricevere supporto valido dai driver open source AMDGPU e RADV, quindi il collo di bottiglia in questo scenario non è principalmente grafico ma legato alla gestione CPU.

Il lavoro di Zijlstra evidenzia anche un dettaglio interessante: molte ottimizzazioni recenti del kernel sono nate pensando a server e datacenter multi core, mentre i carichi desktop interattivi hanno esigenze completamente diverse.