cgroup

Quando si parla di gaming su Linux, raramente si pensa a un chip del 2011 come banco di prova. Eppure è proprio quello che è successo con una macchina equipaggiata con un Intel Core i7-2600K, una Radeon RX 580 e un gioco Windows eseguito tramite Proton: una configurazione definita ironicamente "potato" che ha prodotto risultati sorprendenti grazie al lavoro di Peter Zijlstra, storico sviluppatore del kernel Linux, ingegnere Intel e figura centrale nello sviluppo dello scheduler. Il cuore della questione riguarda la gestione della schedulazione dei processi nei cosiddetti cgroup, ovvero quel meccanismo che Linux utilizza per suddividere risorse CPU, memoria e I/O tra gruppi di processi diversi. Container, sandbox, servizi systemd e perfino alcune sessioni gaming sotto Steam passano tutti da lì. Il sistema è estremamente flessibile, ma la complessità dello scheduler è cresciuta parecchio negli anni, soprattutto con l'aumento dei core e dei thread disponibili sulle CPU moderne. Secondo Zijlstra, parte dell'algoritmo attuale disperde il peso dei task tra i vari core in modo inefficiente, con effetti collaterali evidenti nei carichi interattivi come il gaming. 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 male il tempo di elaborazione tra i processi, le conseguenze vanno ben oltre un calo del frame rate medio. Si manifestano scatti nelle animazioni, blocchi improvvisi e tempi di rendering irregolari. Per verificare il comportamento dello scheduler, Zijlstra ha eseguito "Shadows: Awakening" tramite Lutris con GE-Proton10-34 e Steam Runtime 3 "sniper", avviando in parallelo 8 processi chiamati spin.sh, impostati con priorità ridotta tramite il parametro nice. Si tratta di script che eseguono continuamente operazioni cicliche, occupando la CPU senza fare nulla di utile, simulando una situazione di saturazione molto realistica: browser con tante schede aperte, Discord, streaming, compilazioni in background. La modifica alle time slice e i numeri che parlano da soli Il risultato iniziale era 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. Qui arriva la parte davvero interessante: Zijlstra ha ridotto drasticamente la dimensione della time slice assegnata dallo scheduler, portandola a un decimo del valore base. L'obiettivo era capire se una distribuzione più aggressiva del tempo CPU potesse migliorare la responsività complessiva della macchina. I numeri raccolti tramite MangoHUD sono eloquenti. Gli fps minimi sono passati da 3,8 a 20,6. Il frame time massimo è sceso da 107,4 ms a 37,2 ms. E il frame time medio è passato da 34,5 ms a 19,5 ms. Il dato sugli fps medi, preso isolatamente, dice poco: il salto più significativo riguarda la stabilità dell'esperienza. Un frame time superiore a 100 ms produce micro blocchi chiaramente percepibili anche da chi non è particolarmente esperto, e ridurre quei picchi cambia completamente la sensazione durante il gameplay. Quelle messe a punto da Zijlstra non sono ancora patch definitive pronte per il merge nel ramo principale del kernel Linux. Il lavoro fa parte di una revisione più ampia che dovrebbe arrivare a maturazione in tempi ragionevoli. Perché l'hardware vecchio rende tutto più evidente Le CPU Sandy Bridge come il Core i7-2600K si comportano in modo molto diverso rispetto ai processori recenti. Mancano tante ottimizzazioni introdotte negli anni: scheduler hardware più sofisticati, cache più ampie, meccanismi avanzati di power management e gestione delle latenze. Il 2600K ha 4 core fisici con Hyper-Threading, per un totale di 8 thread logici, e in scenari di saturazione la competizione tra thread diventa feroce. Le inefficienze dello scheduler emergono subito. È proprio l'hardware vecchio a rendere più visibili certi 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 particolare, perché Polaris continua a ricevere supporto valido dai driver open source AMDGPU e RADV. Il collo di bottiglia in questo scenario non è grafico ma legato alla gestione CPU. Il lavoro di Zijlstra evidenzia anche un altro aspetto: molte ottimizzazioni recenti del kernel Linux sono nate pensando a server e datacenter multi core, mentre i carichi desktop interattivi hanno esigenze completamente diverse.

cgroup

Linux: le patch allo scheduler che fanno volare anche i PC più datati