Your Old Potato PC Might Game Better With This Linux Kernel Patch
As a gamer, if you have gamed on Linux with hardware that's seen better days, there's some work happening in the kernel that's worth keeping an eye on.
Linux kernel developer Peter Zijlstra has posted the second version of a patch series called "sched: Flatten the pick," aimed at fixing gaps in how the Linux scheduler handles cgroup scheduling.
Calling it "a pain in the ar*e," he has tracked the issue down to a formula that fragments a task group's total weight across every CPU on the system.
On a 64-core machine, Peter says, a cgroup is already down to roughly a nice 19 task worth of priority per CPU, and at 256 cores, which is not unusual in servers today, the margin gets even tinier.
He breaks the rest of the problem into two parts, where the usual fix for the first is to inflate the group weight by the CPU count, but when all of a group's load lands on a single CPU, that weight balloons well past nice -20 (priority value of the process), and the math starts breaking down.
The second is how the scheduler picks the next task to run. It currently has to step through multiple cgroup levels to get there; the fix collapses all of that into a single level instead.
He ran what he calls a little experiment, using an older configuration with an Intel Core i7-2600K and AMD Radeon RX 580, loading up Shadows: Awakening from GOG through Lutris, using GE-Proton10-34 and Steam Runtime 3 (sniper).
To properly stress the setup, he threw 8 spinner processes at it alongside the game, one per CPU thread, and watched it go from playable to "almost unplayable, as in proper terrible."
He then restarted it with a shorter scheduler time slice set to one-tenth of the default via chrt and recorded both sessions using MangoHud. This is what he got. 👇
| Metric | Default slice | Shorter slice |
|---|---|---|
| FPS min | 3.8 | 20.6 |
| FPS avg | 48.0 | 57.2 |
| FPS max | 87.4 | 80.3 |
| Frame time min (ms) | 9.4 | 8.4 |
| Frame time avg (ms) | 34.5 | 19.5 |
| Frame time max (ms) | 107.4 | 37.2 |
Closing the proposal, Peter said that he has not compared to a kernel without flat on, just wanted to run non trivial workloads and play with slice to make sure everything 'works.'
Should you be excited?
If you game on Linux, especially on older hardware, this kind of fix can be beneficial.
The stress test Peter ran is not that far from what happens in normal use. Discord, a web browser with a dozen tabs, a system update running in the background. They all compete for CPU time the same way those spinner processes did.
And while his test rig is old, the scheduler problem is not limited to old hardware. High core counts make the weight fragmentation issue worse, not better. If this lands, modern rigs with 16 or more cores could see gains too.
You should also know that this has not made it into the mainline Linux kernel yet. The patch series still needs review from the concerned kernel maintainers. It will almost certainly go through some revisions before it lands in a kernel release.
Via: Phoronix
Source: It's FOSS