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

[Djhg2000]

That's the package, I didn't looked into. Doesn't make sense to me. I've expected this file in the kernel-package.

For what it's worth, plain Debian supplies the config with the image:

~$ dpkg -S /boot/config-5.4.0-1-amd64
linux-image-5.4.0-1-amd64: /boot/config-5.4.0-1-amd64

Which means this is yet another thing Canonical "fixed" in Ubuntu.

Here are the same config lines as above from that same Debian kernel:

~$ grep PREEMP /boot/config-5.4.0-1-amd64
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPTIRQ_EVENTS is not set
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set

and

~$ grep HZ /boot/config-5.4.0-1-amd64
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_MACHZ_WDT=m

I guess Canonical didn't do much tweaking to the Debian kernel in this regard.

[PuckPoltergeist]

I guess Canonical didn't do much tweaking to the Debian kernel in this regard.

Yes, but Debian isn't known as a desktop distribution like Ubuntu is. It's the opposite, Debian is known as the stable server distro. Latency isn't important for most servers, but throughput is.

[Raka555]

I see you desktop boys are still at it...

One recent example that happened at work was a linux board that went AWOL due to high load. We couldn't even ssh into it reliably because it was "so busy". Compiling has a LOT of empty timeframes to fill in other stuff. It's very light weight load that doesn't utilize the whole system properly.

On the desktop side I definitely got situations in which my mouse was lagging, sound got choppy and I couldn't continue watching youtube. One was with compiling but in addition to another runaway process. I think compiling alone is just not "good enough" to cause this.

It MIGHT be related to IO as well but why should 3rd party IO cause issues with something that's not even using the disk/resource? Ask yourself that...

This sounds a lot like out of memory type behaviour ...

[F.Ultra]

That's the package, I didn't looked into. Doesn't make sense to me. I've expected this file in the kernel-package.


Yep, already replied.


A middle ground isn't good, neither for desktop than for server. They should provide lowlatency per default and a kernel for servers alternatively.

They had a server specific and desktop specific kernel until 12.04 when they merged to use a single kernel by default regardless of server/desktop. Truth be told I've not seen any problems with their kernel for my desktop use (including video+audio and gaming) and I do think that with today's higher core count (I have basically a load average of 0.10 right now) there is less to gain from a highly preemtive kernel unless you really have a need for (somewhat) deterministic latency with e.g audio capture with JACK and even then using SCHED_FIFO and thread affinity that should not require a true preemtive kernel either.

When people notice problems like Almindor did it's 99.99999% more likely to be something other than then scheduler anyway.

Unless of course if you create your own hipster spinlock in userspace and think that every OS will treat that equally :-). Should probably be the next thing for Ferals Gamemode to boost the thread priority of the running game (unless they already do this).

[knweiss]

Linus joins the discussion with a long comment in the RWT forum: https://www.realworldtech.com/forum/...rpostid=189723

TL;DR "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."

[F.Ultra]

Linus joins the discussion with a long comment in the RWT forum: https://www.realworldtech.com/forum/...rpostid=189723

TL;DR "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."

Thanks for that post from Linus, it's good to know that we weren't on the wrong side of the Dunning-Kruger scale on this matter

[PuckPoltergeist]

Linus joins the discussion with a long comment in the RWT forum: https://www.realworldtech.com/forum/...rpostid=189723

TL;DR "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."

I'm waiting for the comments on Linus' explanations.

[indepe]

Linus joins the discussion with a long comment in the RWT forum: https://www.realworldtech.com/forum/...rpostid=189723

TL;DR "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."

Thanks for the reference. Linus' posts make for an interesting read. (There are now 4 of them.)

[knweiss]

Thanks for the reference. Linus' posts make for an interesting read. (There are now 4 of them.)

BTW: The GNU make bug Linus mentions (it causes sever performance hits in parallel builds) is an interesting story by itself. Here‘s the thread: https://lkml.org/lkml/2019/12/9/687

It‘s remarkable how long this remained undetected/unfixed.

[Ardje]

So, once again, windows gaming gets better, because developers now realize how to use locking better thanks to Linus's lectures on how to do locking.
Anyway, I think the developer is good in the sense he is open about his findings. This shows that a lot of developers did not learn how to lock. Their programs could have even behaved better with this knowledge.
I just hope the developer can grok the directness of Linus. I love his directness, although I think I would have problems swallowing a few minutes when directed at me.