The Linux Kernel's Scheduler Apparently Causing Issues For Google Stadia Game Developers

[phoronix]

Phoronix: The Linux Kernel's Scheduler Apparently Causing Issues For Google Stadia Game Developers

Among the issues that game developers have been facing in bringing their games to Linux for Google's Stadia cloud gaming service apparently stem from kernel scheduler issues. We've known the Linux kernel scheduler could use some improvements and independent developers like Con Kolivas with BFS / MuQSS have pushed for such, but hopefully in 2020 we'll see some real action...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-2020-Scheduler-Bugs-Stadia

[cb88]

It doesn't' help that they don't' understand physics or how to deploy software in a reliable and consistent manner....

[Aeder]

It would be nice if these findings lead to patches that improve perfomance on non-stadia games.

[Unklejoe]

Spinlocks in userspace are a huge reg flag to me...

For one, there’s no way to reliably implement them since you can’t really stop the thread that’s holding it from being scheduled out, leaving any threads that are waiting for the lock just sitting there until they’re finally scheduled out and the original thread can resume and drop the lock.

[programmerjake]

Very interesting!

[discordian]

Spinlocks in userspace are a huge reg flag to me...

For one, there’s no way to reliably implement them since you can’t really stop the thread that’s holding it from being scheduled out, leaving any threads that are waiting for the lock just sitting there until they’re finally scheduled out and the original thread can resume and drop the lock.

Bingo. Unless you have some read-only locks with lazy updates, at which point you should use some existing package like URCU. Plain spinlocks are evil, often even in kernelspace.

[Zan Lynx]

Spinlocks in userspace are a huge reg flag to me...

The way glibc implements futexes on Linux uses userspace spinlocks. It's not unusual. It's pretty much the standard anywhere.

A futex (Fast Userspace Mutex) tries to get the lock a few times before going into the kernel. Windows CriticalSection does exactly the same thing.

Now, some game or database (cough, Postgres, cough) that has their own custom spinlock implementation is probably wrong and buggy on Linux. Replacing it with standard pthread_mutex calls is almost certain to be an improvement since those are properly tuned for Linux expectations.

[discordian]

A futex (Fast Userspace Mutex) tries to get the lock a few times before going into the kernel. Windows CriticalSection does exactly the same thing.

Yes, but it does not do so infinitely, it is not a spinlock. At best the non-spinlock is a part of the futex, the part is typically called lock-elision.

[betam4x]

The "developers" complaining of this have absolutely no idea what they are doing. While I don't have access to the code at hand, one need only look at rage 2 running under Wine to determine that an incorrect approach is being taken if they are struggling to hit 60 fps on a native port. Note that Rage 2 runs at more than 100fps under proton depending on your hardware.

[jKicker]

The "developers" complaining of this have absolutely no idea what they are doing. While I don't have access to the code at hand, one need only look at rage 2 running under Wine to determine that an incorrect approach is being taken if they are struggling to hit 60 fps on a native port. Note that Rage 2 runs at more than 100fps under proton depending on your hardware.

I hope in 2020 people actually take the time to read the topic they are commenting on in full. Here you go once again - https://probablydance.com/2019/12/30...uler-really-is.
Please also read the comments,

Thanks.