Lo scheduler di Linux causa problemi agli sviluppatori di Google Stadia
Gli sviluppatori di Google che lavorano al progetto Stadia stanno incontrando problemi nel porting dei giochi a causa dello scheduler di Linux. Alcuni sviluppatori indipendenti hanno apportato alcune modifiche allo scheduler ma non è ancora sufficiente.
Cos’è lo scheduler?
Per rendere l’articolo comprensibile a tutti non posso esimermi dallo spiegare brevemente cos’è uno scheduler.
Lo scheduler è un componente fondamentale dei sistemi operativi multitasking, cioè quelli in grado di eseguire più processi (task) contemporaneamente. Lo scheduler si occupa di fare avanzare un processo interrompendone temporaneamente un altro, realizzando così un cambiamento di contesto (context switch). Generalmente computer con un processore sono in grado di eseguire un programma per volta, quindi per poter far convivere più task è necessario usare lo scheduler. Esistono vari algoritmi di scheduling che permettono di scegliere nella maniera più efficiente possibile quale task far proseguire.
Cos’è Google Stadia
Breve riassunto anche per quanto riguarda Google Stadia. Stadia è il nuovo servizio di Big G dedicato ai videogiocatori. Si tratta di una piattaforma di streaming pensata per permettere ai giocatori di divertirsi su qualsiasi dispositivo: dai PC agli smartphone, dai tablet fino alle TV dotate di Chromecast o app dedicate. Da oggi Google Stadia è disponibile anche in Italia. Come funziona? Quanto costa? Quando arriverà la versione gratuita? Per tutte le risposte vi rimando all’articolo dedicato.
I problemi: scheduler Linux & Google Stadia
Lo sviluppatore Malte Skarupke ha scritto un post riguardo questi problemi dello scheduler.
L’implementazione dei mutex è okay ma quella degli spinlock no, lo scheduler funziona ma è lontano dall’essere perfetto. Il suo rimpiazzo più popolare, lo scheduler MuQSS, ha altri problemi mentre lo scheduler di Windows è abbastanza buono.
I problemi di Skarupke sono iniziati quando ha riscontrato misteriosi stalli nel porting di Rage 2 su Stadia.
L’unica cosa in comune a tali stalli è data dal fatto che usano gli spinlock. Situazione curiosa dato che sono stato proprio io a scrivere gli spinlock. Il problema è che un thread impiega diversi millisecondi per acquisire uno spinlock anche quando nessun altro thread ne è in possesso. Ripeto: lo spinlock era libero. In un videogioco dove bisogna mostrare un’immagine a schermo ogni 16 ms (o 33 ms, dipende dalla frequenza) uno stallo che impiega più di 1 ms è terribile. Siamo riusciti a risolvere il problema rimpiazzando gli spinlock con i mutex.
Google è assolutamente al corrente del problema. Sono molto interessati alla latenza perchè è importantissima per l’esperienza utente su Stadia. Uno dei modi con cui hanno cercato di abbassarla è stato alzare la frequenza operativa a 60 Hz anche per i giochi che funzionano a 30 Hz. Ciò significa che si hanno a disposizione solo 16 ms per ottenere un frame sullo schermo e se lo scheduler funziona così male è un disastro. Malte Skarupke ha risposto al lead developer di MuQSS:
Se riuscite a risolvere questo problema degli spinlock consiglierei il vostro scheduler senza riserve rispetto agli altri. Quindi questa potrebbe essere un’opportunità per portare MuQSS nel kernel Linux (mainline) e magari Google stessa potrebbe iniziare ad utilizzarlo.
Skarupke ha anche postato del codice benchmark da usare per fare dei test.
Seguiteci sul nostro canale Telegram, sulla nostra pagina Facebook e su Google News. Nel campo qui sotto è possibile commentare e creare spunti di discussione inerenti le tematiche trattate sul blog.