![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Google Stadia Port Troubles Blamed on the Linux Kernel Scheduler
- Thread starter Auer
- Start date
https://www.phoronix.com/scan.php?page=news_item&px=Torvalds-On-Scheduler-Woes
I'll just post the meat of it here..... and as anyone with a brain has been saying. These game developers are shit.... using spinlocks in 2019/20 is fucking stupid. It shows that these morons are used to working with a OS with a shit scheduler.
In a mailing list discussion on the reported Linux kernel troubles, Linus 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."
Linus went on to add, "So what's the fix for this? 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." See his post in full for a lot more interesting technical details.
I'll just post the meat of it here..... and as anyone with a brain has been saying. These game developers are shit.... using spinlocks in 2019/20 is fucking stupid. It shows that these morons are used to working with a OS with a shit scheduler.
In a mailing list discussion on the reported Linux kernel troubles, Linus 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."
Linus went on to add, "So what's the fix for this? 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." See his post in full for a lot more interesting technical details.