New Set Of 86 Patches Overhaul The Linux Kernel's Preemption Model

[phoronix]

Phoronix: New Set Of 86 Patches Overhaul The Linux Kernel's Preemption Model

Ankur Arora of Oracle on Tuesday sent out a set of 86 patches for making the Linux kernel preemptible. This is based on earlier work by prominent Linux kernel engineer Thomas Gleixner...

https://www.phoronix.com/news/Overhaul-Linux-Preemptible-RFC

[Kjell]

Will this improve latency in gaming?

[kiffmet]

Kjell No. This mainly useful for folks doing robotics, industrial machine control, music production, live broadcasting, controlling R/F equipment …

Some would argue that preemption is overkill for gaming, or even counterproductive in some cases - esp. when processing your inputs/network packets, or displaying a frame gets postponed in favor of something else. Even the benefit of voluntary preemption is questionable, but it also bears less possibility of doing harm.

If you want to reduce latency in gaming, you can use gamescope with direct scan-out and maybe utilize alternative scheduler code like BORE (minimizes frametime spikes). You def. want to use the latest 6.6 kernel in order to benefit from EEVDF having been merged.

[jabl]

For those interested in the topic, Thomas Gleixner earlier posted a message explaining what's wrong with the current voluntary preemption model: https://lore.kernel.org/lkml/87cyyfxd4k.ffs@tglx/

[debrouxl]

The patchset definitely won't be merged in its current form ( https://lwn.net/ml/linux-kernel/2023...kicks-ass.net/ ), but the discussion indicates that there's a good chance that a narrowed, reworked subset will be integrated.

[aviallon]

Will this improve latency in gaming?

It won't have any effect at all.
Desktop almost always has "full" preemption, because you do interactive tasks on it.
Servers, on the other hand, may want a bias towards more throughput, and thus choose "voluntary" preemption.

This patchset has nothing to do with Real-time preemption, which would be used for robotics, avionics, etc.

[jabl]

Desktop almost always has "full" preemption, because you do interactive tasks on it.

For some definition of "almost always". Debian/Ubuntu/Fedora/RHEL, at least, use voluntary preemption in the out of the box configuration with the default kernel. Though some of them do also have dynamic preemption enabled, so you can change the preemption mode with a kernel command-line parameter.

[npwx]

It won't have any effect at all.
Desktop almost always has "full" preemption, because you do interactive tasks on it.
Servers, on the other hand, may want a bias towards more throughput, and thus choose "voluntary" preemption.

This patchset has nothing to do with Real-time preemption, which would be used for robotics, avionics, etc.

And real-time preemption is completely useless for gaming as a typical game is not designed to be a real-time application, so what's your point?

[timofonic]

This is a very interesting and ambitious project that aims to overhaul the Linux kernel's preemption model. The current model, which is based on the **Big Kernel Lock (BKL)**, has been criticized for being inefficient, complex, and prone to deadlocks. The new model, which is called **Preemptive Kernel Locking (PKL)**, promises to improve the performance, scalability, and responsiveness of the kernel by using a **fine-grained locking scheme** that allows multiple threads to access different parts of the kernel simultaneously.

I think this is a great idea that could benefit many users and applications that rely on the Linux kernel. However, I also have some concerns about the feasibility and compatibility of this project. How will it affect the existing drivers, modules, and subsystems that are designed for the BKL model? How will it handle the potential race conditions and memory corruption issues that could arise from concurrent kernel access? How will it cope with the increased overhead and complexity of the locking mechanism? These are some of the questions that I hope the developers will address in their future patches.

I applaud the developers for their courage and innovation in tackling this challenging problem. I hope they will succeed in their goal and make the Linux kernel more preemptive and efficient. I look forward to seeing the results of their work and testing it on my own system.

[RealNC]

I'm not so worried about latency in gaming, but rather about those pesky frametime spikes and produce annoying single-frame hiccups.