O Google Stadia można bez większej przesady powiedzieć, że to jeden z największych niewypałów minionego roku. Coś, co miało zrewolucjonizować rozgrywkę i w końcu, pod skrzydłami Google, zostać wykonane w sposób satysfakcjonujący graczy, okazało się wczesną (płatną) wersją testową, która dostarczała wielu wrażeń, ale na pewno nie rozrywki. W ostatnim czasie pojawiły się sugestie, że wynika to z problemów jądra Linux. W swoim stylu do tych oskarżeń ustosunkował się Linus Torvalds.
Dotąd swoich sił w strumieniowaniu gier próbowało wielu. Nic dziwnego, mowa o perspektywie ostatecznego przełamania lokalnych ograniczeń sprzętowych i zaprzęgnięcia potęgi infrastruktury chmurowej do napędzania fenomenalnie spieniężającej się branży gier. Wielu miało nadzieję, że Google będzie w stanie udźwignąć narzut na infrastrukturę, ale na razie nadzieje te okazały się płonne. Niestety, ze względu na lagi, ograniczenia w obsłudze grafiki i małą liczbę tytułów, Stadia na razie rozczarowuje.
Taki stan rzeczy był dla wielu powodem do nie lada rozgoryczenia, co nie powinno dziwić. Wszak Google za niskiej jakości niedokończoną usługę kazało sobie płacić. W rezultacie zaczęto poszukiwać czynników technicznych, które mogły być powodem bylejakości Google Stadia. Jak donosi Michael Larabel, portujący gry na Stadię deweloper Malte Skarupke podzielił się spostrzeżeniami, że jednym z wyzwań w jego pracy są niedoskonałości planisty wykorzystywanego w Linuksie. Aktualnie jest nim Completely Fair Scheduler.
Według Skarupke problemy z CFS wynikają przede wszystkim z opóźnień w dostępie do tzw. spinlocków, czyli mechanizmów, które mają zapobiegać jednoczesnemu wykorzystaniu tych samych zasobów przez więcej niż jeden proces. Według dewelopera czas oczekiwania na dostęp do spinlocka to na gruncie Linuksa i Stadii nawet więcej niż milisekunda, co w przypadku renderowania w 30 lub 60 Hz jest niewybaczalne, gdyż klatki muszą być wyświetlane co 16 lub 33 milisekundy, w zależności od częstotliwości odświeżania.
Na reakcję Linusa Torvaldsa nie trzeba było czekać długo. Nie zostawił on na spostrzeżeniach Skrupke suchej nitki, zarzucając deweloperowi, że dokonane przez niego pomiary dotyczą zupełnie innych aspektów działania linuksowego planisty, nie zaś czasu dostępu do spinlocków, które mogłyby powodować opóźnienia. Ponadto Torvalds zwraca uwagę, że deweloper używał spinlocków niezgodnie z ich zastosowaniami, a całość podsumował stwierdzeniem, że wyniki testów to „zwyczajne śmieci”.
