Infinity Scheduler è il nome del nuovo componente pensato per rendere più reattivo Linux quando la CPU è sotto pressione. Capita spesso: il processore è potente, eppure il computer sembra arrancare. Il motivo? Troppi processi che chiedono attenzione tutti insieme. Il browser con venti schede aperte, una videochiamata in corso, l’ambiente grafico, magari un rendering che macina in sottofondo e pure un gioco. In queste situazioni non conta soltanto quanta potenza sia disponibile, ma come il sistema operativo decide a chi darla. Ed è esattamente qui che Infinity Scheduler prova a mettere ordine.
L’idea di fondo è semplice da spiegare. Se un programma occupa la CPU senza mai fermarsi, lo scheduler tende a ridurne progressivamente il turno di esecuzione. Se invece un’applicazione si sveglia solo per rispondere a un clic, a un evento audio o a una breve operazione interattiva, prova a darle la precedenza. In pratica, distingue chi sta divorando risorse da chi ha bisogno di rispondere subito. Un modo per rendere qualunque distribuzione Linux più pronta nelle situazioni concrete di ogni giorno.
Perché lo scheduler conta così tanto
Lo scheduler è una di quelle parti del sistema operativo che nessuno vede mai, ma che lavora senza sosta dietro le quinte. Quando il mouse scatta mentre il computer è impegnato in un’attività pesante, quando l’audio gracchia sotto carico, quando una finestra risponde in ritardo, il colpevole raramente è una singola applicazione. Il problema sta nel modo in cui il sistema distribuisce il tempo CPU tra decine o centinaia di thread.
Una CPU moderna cambia attività migliaia di volte al secondo. Ogni processo riceve il suo turno, poi cede spazio a un altro. Il punto cruciale è decidere quanto deve durare quel turno e quale processo debba subentrare. Un’applicazione che comprime file, compila codice o esegue calcoli pesanti può tenere occupata la CPU per lunghi periodi. Un’app interattiva, al contrario, resta spesso dormiente e si risveglia solo per pochi istanti: un clic, un input da tastiera, un pacchetto di rete, un buffer audio da riempire. Se il sistema tratta questi comportamenti in modo troppo simile, l’esperienza peggiora. Il computer continua a lavorare, ma la percezione è quella di un ritardo evidente.
Cosa cambia rispetto agli altri scheduler
Per anni Linux si è affidato soprattutto a CFS, il Completely Fair Scheduler, pensato per distribuire il tempo della CPU in modo equo tra i processi. Poi il kernel ha iniziato ad adottare EEVDF, con una logica più attenta alle scadenze virtuali e alla latenza. In parallelo, sched_ext, finito di recente sotto le critiche dirette di Linus Torvalds per la struttura dei sorgenti, ha aperto la strada agli scheduler sperimentali basati su BPF. Con Infinity Scheduler si prende una direzione diversa, con modifiche incentrate direttamente sul cuore del kernel.
Il nuovo scheduler non osserva Linux dall’esterno. Agisce dentro i meccanismi con cui il sistema aggiorna il tempo di esecuzione dei processi, i risvegli delle attività sospese, le code dei task pronti a partire e le priorità assegnate nel tempo. Il suo meccanismo centrale usa una media mobile esponenziale: il kernel tiene conto del comportamento recente di ogni processo. Se un task usa la CPU di continuo, il suo valore cresce. Se resta spesso in attesa e si sveglia solo per operazioni brevi, quel valore resta più basso.
Questa informazione serve ad adattare il turno di esecuzione. I task più pesanti possono vedere ridotta la finestra d’uso della CPU fino a un limite di 400 microsecondi. Un valore bassissimo, ma non significa che quei processi vengano bloccati. La conseguenza è che sono chiamati a cedere il processore più spesso, lasciando spazio a chi ha bisogno di una risposta immediata.
Un’idea promettente, ma non ancora per tutti
L’obiettivo dichiarato è migliorare le prestazioni dei sistemi Linux e far apparire il computer più pronto proprio quando l’utente ha davvero necessità di interagire. L’approccio è senza dubbio interessante, ma va detto che Infinity modifica parti sensibili del kernel e deve ancora dimostrare, con test indipendenti, di migliorare abbastanza le situazioni reali senza creare regressioni altrove.
Per ora conviene considerarlo un progetto da seguire con attenzione, soprattutto per chi compila kernel personalizzati, sperimenta distribuzioni ottimizzate o lavora sulla latenza desktop. Non è ancora il tipo di modifica da consigliare a chi cerca semplicemente un sistema stabile e prevedibile.