Linux Scheduler Work Helping Boost Gaming Performance On Old "Potato" Hardware
([Linux Kernel] 6 Hours Ago
Flatten The Pick)
- Reference: 0001633022
- News link: https://www.phoronix.com/news/Linux-Flatten-The-Pick
- Source link:
Prominent Linux kernel engineer Peter Zijlstra of Intel has been working on a set of scheduler patches to help with enhancing the behavior and delivering better results, especially for aging hardware he described as a "potato" -- an Intel Sandy Bridge desktop CPU with AMD Radeon RX 580 Polaris graphics. Benchmark results are promising from this work for gaming on old hardware while other workloads may ultimately stand to benefit too.
Zijlstra described Linux cgroup scheduling as " a pain in the arse. The problems start with weight distribution and end with hierachical picks and it all sucks. " So with [1]sched: Flatten the pick patch series, he's working to make some enhancements. Particularly with today's increasing core counts, there are big inefficiencies in the scheduling code to address.
For end users not caring about the Linux kernel scheduler internals, the end result is the interesting "little experiment" he did with the old potato-class hardware:
"For testing, I've done a little experiment, I dug out what is colloqually known as a potato. A trusty old Sandybridge 2600k with a RX 580, and ran a game on it. From GOG, I had available 'Shadows: Awakens', a fun title that normally runs really well on this machine (provided you stick to 1080p).
To make it interesting, I added 8 (one for each logical CPU) copies of: 'nice spin.sh'; this results in the game becoming almost unplayable, as in proper terrible.
I used MangoHUD to record a few minutes of playtime for statistics, and then quit the came and re-started it with a shorter slice set (base/10). This results in the game being entirely playable -- not great, but [definitely] playable.
Lutris / GE-Proton10-34 / Steam Runtime 3 (sniper)
Intel Core i7-2600K
AMD Radeon RX 580
Shadows Awakening (GOG)
default slice(*)
FPS min 3.8 20.6
avg 48.0 57.2
mag 87.4 80.3
FT min 9.4 8.4
avg 34.5 19.5
max 107.4 37.2
FPS (Frames Per Second)
FT (FrameTime)"
Very nice FPS and frame time improvements from this exploration.
It will be very interesting to see how [2]this work evolves and hopefully making it into the mainline Linux kernel as well as seeing the net impact in the end across a range of hardware and workloads.
[1] https://lore.kernel.org/all/20260511113104.563854162@infradead.org/
[2] https://lore.kernel.org/all/20260511113104.563854162@infradead.org/
Zijlstra described Linux cgroup scheduling as " a pain in the arse. The problems start with weight distribution and end with hierachical picks and it all sucks. " So with [1]sched: Flatten the pick patch series, he's working to make some enhancements. Particularly with today's increasing core counts, there are big inefficiencies in the scheduling code to address.
For end users not caring about the Linux kernel scheduler internals, the end result is the interesting "little experiment" he did with the old potato-class hardware:
"For testing, I've done a little experiment, I dug out what is colloqually known as a potato. A trusty old Sandybridge 2600k with a RX 580, and ran a game on it. From GOG, I had available 'Shadows: Awakens', a fun title that normally runs really well on this machine (provided you stick to 1080p).
To make it interesting, I added 8 (one for each logical CPU) copies of: 'nice spin.sh'; this results in the game becoming almost unplayable, as in proper terrible.
I used MangoHUD to record a few minutes of playtime for statistics, and then quit the came and re-started it with a shorter slice set (base/10). This results in the game being entirely playable -- not great, but [definitely] playable.
Lutris / GE-Proton10-34 / Steam Runtime 3 (sniper)
Intel Core i7-2600K
AMD Radeon RX 580
Shadows Awakening (GOG)
default slice(*)
FPS min 3.8 20.6
avg 48.0 57.2
mag 87.4 80.3
FT min 9.4 8.4
avg 34.5 19.5
max 107.4 37.2
FPS (Frames Per Second)
FT (FrameTime)"
Very nice FPS and frame time improvements from this exploration.
It will be very interesting to see how [2]this work evolves and hopefully making it into the mainline Linux kernel as well as seeing the net impact in the end across a range of hardware and workloads.
[1] https://lore.kernel.org/all/20260511113104.563854162@infradead.org/
[2] https://lore.kernel.org/all/20260511113104.563854162@infradead.org/