Linux 6.0 Merges The AMD Performance Fix For The Old "Dummy Wait" Workaround

[kozman]

Cool beans. I donated a fiver to Michael just to see what these metrics will look like against the Zen 4 numbers that went live today. I'm not expecting a cure for cancer here but I would think this chain and anchor finally being shed should increase the MPG a tad, so to speak. We got something to look forward to!

[kozman]

I wonder if this helps the Steamdeck.

Hmm...almost wondered if this fix would help FPS in games? MESA? Not a gamer myself but I am curious as to the scope, extent and benefit of it. We wait with bated breath.

[kozman]

Also, how far back---in old kernel versions---can this be backported? I sat here thinking: If this issued had been found and addressed years ago, imagine how many hours of people's lives wouldn't have gone to waste? Seriously, if there's no impetus to hunt for or create tools to somehow find more of these oddball perf issues, I'd be kind of bummed out. Let the one-upmanship begin? I would love to see a bug bounty thing with this.

[OmniNegro]

The Steamdeck uses a newer CPU that almost certainly does not have the need for this fix.

But if it does need it, you can bet your ass Valve will make it a priority to get it patched ASAP.

[Myownfriend]

The Steamdeck uses a newer CPU that almost certainly does not have the need for this fix.

It effects newer CPUs. The whole issue is that there was a workaround for older Intel CPUs that was being errantly applied to newer AMD CPUs and slows down certain workloads on Ryzen, Epyc, and Threadripper significantly.

https://www.phoronix.com/news/Linux-AMD-Old-Chipset-WA

"Sampling certain workloads with IBS on AMD Zen3 system shows that a significant amount of time is spent in the dummy op, which incorrectly gets accounted as C-State residency. A large C-State residency value can prime the cpuidle governor to recommend a deeper C-State during the subsequent idle instances, starting a vicious cycle, leading to performance degradation on workloads that rapidly switch between busy and idle phases.

One such workload is tbench where a massive performance degradation can be observed during certain runs."

[Linuxxx]

The Steamdeck uses a newer CPU that almost certainly does not have the need for this fix.

But if it does need it, you can bet your ass Valve will make it a priority to get it patched ASAP.

First of all, you're wrong (and not for the first time either, mind you).

Secondly, Valve still ships the Steam Deck with the schedutil CPU governor by default, which is very well known for causing stuttering & frame-time spikes.

Therefore I don't see why they would be in any rush to address this particular issue here, either...

[Valve-time, remember?]

[coder]

My father still uses a notebook with Pentium M (comparable performance from the Athlon XP era) for OBD car diagnostics and it is a complete disaster under any distro that call itself lightweight. Antix, MXLinux, even Debian minimal install struggle just to decently run a desktop. Not saying about running that apps under Wine. And this notebook already has 3Gb of dual channel DDR2 and Intel SATA SSD.

Same, but the issue with it is the video drivers. It's stuck using VESA mode, rather than native acceleration.

Pentium M is probably close to a single core of a Raspberry Pi v4, when it's running AArch32 code.

Using 20+ y/o hardware as a server that can die at any moment? Unless you don't have anything else and you have free electricity.

Yeah, any server too old to have PCIe and SATA isn't worth any time or effort. That heavily limits what kind of storage it can use, which probably means you're using old refurb drives at death's door. Core 2 Duo or AMD Phenom II are about the oldest things I'd even touch.

P.S. the very first fileserver I built used a Pentium 4 with regular PCI SATA controller cards and I/O performance was unbelievably bad. When I upgraded to a Phenom II, the RAID sustained I/O was easily > 10x faster, for some inexplicable reason.

[HD7950]

After this patch i have a lot of slowdowns on Yuzu that I didn't have before.

amd-pstate + schedutil + 5950x

[dragorth]

After this patch i have a lot of slowdowns on Yuzu that I didn't have before.

amd-pstate + schedutil + 5950x

This could mean Yuzu's dev was working around this somehow, even if they didn't know they were, and the fix broke that. It could also be Yuzu is sensitive to these types of changes, which is quite probable due to the nature of emulation.

[Anux]

You have no idea what you're talking about. No, 20 years old PCs aren't "more than capable", they're pure garbage for any purpose.

My Duron 800 says you're wrong, while ripping 3 CDs with EAC over wine, checking them for correctnes, auto naming them and converting to flac.

If not for the performance, because, you like to do things in 5 minutes instead of 5 seconds for some reason, then for the ludicrous power drain compared to current systems. The things these pieces of junk can pull in 100W can be done with a 4W Raspberry pi now. Why would you do that, seriously.

Because old hardware is here and costs nothing while new stuff needs to be purchased.

And lightweight distros don't ship bleeding edge releases anyway, for that matter.

Arch Linux 32 is currently at 5.18 but will ship 6.0 if its ready.