Yes, because that's not the main focus of a general-purpose kernel. Which doesn't mean there aren't ways around it if your objective is running Linux for a specific application.
The real time patches are in the mainline kernel since some time ago, but there are other options for softer RT at the kernel as well.
What you can do is make mutexes perfectly adaptive so that they switch to a blocking wait as soon as the lock owner itself gets preempted. I have a proposal to do that here: https://lore.kernel.org/lkml/CAKOZuesa338sc_=w6-wvro25idrSN_...
You should always use waiting primitives when possible instead of just spinning. If you tell the kernel what you're doing, the kernel can help you. If you hide the wait DAG from the kernel, it can't.
If people are learning bad practice from the texts, and the bad practice hits Linux's scheduler asymmetrically hard (relative to other game platforms), one can expect outsized impact on the performance of games atop Linux architectures.
We may need updated books.
"Don't use spinlock" is like "the user is holding it wrong" for API. The user can either choose to modify their behavior or throw up their hands and not port to Linux.
Fundamentally, you need to tell the kernel what you're doing so it can help you. There's no fix here.
And given the over-arching topic of performance in Stadia, it may behoove Google to fork Linux and specialize the scheduler implementation to be more spinlock-friendly. Especially if Linux's benevolent dictator for life is telegraphing he doesn't consider it an interesting problem to solve.
No, it cannot be fixed, because the kernel simply does not have enough information in the case of naive spin locks to make good scheduling decisions. I understand the Chesterton's-fence argument in favor of learning why game developers use spin locks before telling them to do something else, but in this case, I really think simple ignorance is the most likely explanation.
You never want a spinlock in userspace. Period. An adaptive mutex will give you what you want without the pathological downsides.
Look: your whole line of reasoning here is just bizarre and invalid. You can't say "well, maybe there's a reason they're doing it!" without actually backing this claim up with specific reasoning. Sorry, but you can't keep using your spinlocks even if they "work" on other platforms. If they "work" there, it's an accident.
What if you've already used them in code that runs in N other architectures, the game works fine in those architectures, and Linux is architecture N+1, which you're trying to decide to support or not?
The less the code has to be changed, the easier it is to support architecture N+1.
If it cannot be fixed, then why is it only a problem for Linux?
It may be useful to explore why they teach those techniques before passing judgement on a whole ecosystem of educational material.
You can implement spinlocks in userspace under specific circumstances. You will need to mark your threads as realtime threads[0] and have a fallback to futex if the fast path (spinning) doesn't work out. And even then you need to benchmark on multiple machines and with realistic workloads (not microbenchmarks) to see whether it's actually worth it for your application. It's complex, linus goes into more detail here[1]
[0] http://man7.org/linux/man-pages/man3/pthread_spin_init.3.htm... [1] https://www.realworldtech.com/forum/?threadid=189711&curpost...
https://docs.microsoft.com/en-us/cpp/cppcx/wrl/criticalsecti...
Care to elaborate upon this statement?
> "Linux pessimizes for high-performance games atop its kernel."
Games can run at quite a high performance (which feels like a really odd statement) atop the general purpose Linux kernel. Even with the windows-specific APIs being emulated with Wine/Proton.
There are many modern games, including Doom 2016 as I mentioned below) which run beautifully on Linux.
I wouldn't redo the work of people who have literally written books on the topic (https://books.google.com/books?id=1g1mDwAAQBAJ&pg=PA319&lpg=...). Copyright 2019, so if it's not conventional wisdom that spinlocks are the right tool any longer, the "best practices" in game education are still teaching them, and OS's may need to account for the code actually written, not the code they wish were written.
I don't think this should be asserted in such a black-and-white way. Yes, platforms need to accommodate the programming styles of users. But accommodating them blindly, when better solutions exist, is how you get bad APIs that age poorly.
In platforms that are aiming for long-term stable APIs, it may make more sense in some cases to prioritize the cleanliness of the API over developer patterns, given that developer patterns are easier to change.
Anticipated response:
> "but that won't happen and gaming on linux will be too niche and will die."
To be quite frank, that sounds like a satisfactory outcome to me. If Google wants a different status quo, they should throw more money at the problem rather than telling game developers to moan about it. You don't hear game developers moaning about this sort of shit when porting their games to the FreeBSD-backed PS4, presumably because Sony, unlike Google, actually gave a damn and made sure the platform worked and made sure developers knew how it works. If the requisite work has already been done on FreeBSD, then maybe Google should have decided to use that instead. Either way, it's on them. They made this mess for themselves.
> OS's may need to account for the code actually written
I absolutely disagree with this idea, particularly as it's related to spinlocks. Spinlocks are such a low level, inefficient, method of acquiring a lock that using them as a de-facto method of acquiring a lock is a terrible idea.
Especially as more and more gaming occurs on devices with batteries. Any moderately sane OS will treat the resulting device heat increase and increased battery draw as a trigger to degrade CPU performance, hurting the game performance even more than using a sane lock acquisition method.