Torvalds calls it 'pure garbage' that Linux is to blame for Stadia port issues
Linus Torvalds has called a blogger's claim that Linux is to blame for Google Stadia port issues "pure garbage".
In a blog post, developer Malte Skarupke pointed the finger at the Linux scheduler as being the culprit for issues when porting games to Google's cloud gaming platform Stadia.
Every millisecond delay impacts the experience when gaming. Skarupke gave this overview as to why he came to the conclusion the scheduler was causing the problem:
"I overheard somebody at work complaining about mysterious stalls while porting Rage 2 to Stadia. The only thing those mysterious stalls had in common was that they were all using spinlocks. I was curious about that because I happened to be the person who wrote the spinlock we were using.
The problem was that there was a thread that spent several milliseconds trying to acquire a spinlock at a time when no other thread was holding the spinlock. Let me repeat that: The spinlock was free to take, yet a thread took multiple milliseconds to acquire it.
In a video game, where you have to get a picture on the screen every 16ms or 33ms (depending on if you’re running at 60Hz or 30Hz), a stall that takes more than a millisecond is terrible. Especially if you’re literally stalling all threads."
After months of investigating the issue, Skarupke concluded that "most mutex implementations are really good, that most spinlock implementations are pretty bad and that the Linux scheduler is OK but far from ideal." Skarupke decided to switch from a spinlock to a mutex.
Torvalds decided to personally look into Skarupke's claim and rebuked it in his characteristic no-nonsense manner.
In a mailing list discussion relaying his findings, Torvalds wrote:
"The whole post seems to be just wrong, and is measuring something completely different than what the author thinks and claims it is measuring.
First off, spinlocks can only be used if you actually know you're not being scheduled while using them...It basically reads the time before releasing the lock, and then it reads it after acquiring the lock again, and claims that the time difference is the time when no lock was held. Which is just inane and pointless and completely wrong.
That's pure garbage."
In order to fix the problem highlighted by Skarupke, Torvalds suggests that developers "use a lock where you tell the system that you're waiting for the lock, and where the unlocking thread will let you know when it's done, so that the scheduler can actually work with you, instead of (randomly) working against you...I repeat: do not use spinlocks in user space, unless you actually know what you're doing. And be aware that the likelihood that you know what you are doing is basically nil."
In a way, Skarupke is correct in his findings that spinlocks are causing issues with Linux-to-Stadia ports… But, according to Torvalds, only because they shouldn't be used in such a manner.
Interested in hearing industry leaders discuss subjects like this and sharing their use-cases? Attend the co-located 5G Expo, IoT Tech Expo, Blockchain Expo, AI & Big Data Expo, and Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London, and Amsterdam.
- » Ripple’s dev platform Xpring is ‘building bridges’ with Ethereum
- » GDC State of the Game Industry 2020: Key trends for the year ahead
- » Block.One posts a $200k reward for whoever can build an Ethereum VM for EOS
- » Linux Foundation and LISH publish latest open-source census with suggestions to boost security
- » Raspberry Pi 4 is now OpenGL ES 3.1 conformant, Vulkan incoming