A 20 Year Old Chipset Workaround Has Been Hurting Modern AMD Linux Systems

[stormcrow]

This was obviously found by someone doing workload profiling and then going on a hunt for the offending "dummy reads", as indicated in the patch:

"Sampling certain workloads with IBS on AMD Zen3 system shows that a significant amount of time is spent in the dummy op"

The way you phrased it makes it sound like the issue was discovered through code inspection.

You still have to know to go looking to find anything. In some cases you have to build the tools to even go looking. This sounds like heat mapping of performance data in the kernel. While I've read several articles about using heat maps to visualize profiling data, it's only been for the past few years that it's really become a Thing. It's not just AMD that could have carried out the analysis, anyone with enough curiosity could have done so, but no one did till now. That's supposedly the benefit of FOSS, but only if people actually go looking which is also its Achilles heel. In point of fact, I've run into so much "common wisdom" in the Linux development community that's turned out to be utterly wrong once I went looking (in the source), that I wonder if anyone really is looking outside of the code maintainers - and I'm not even a C developer. What's everyone else's excuse??

[kozman]

You still have to know to go looking to find anything. In some cases you have to build the tools to even go looking. This sounds like heat mapping of performance data in the kernel. While I've read several articles about using heat maps to visualize profiling data, it's only been for the past few years that it's really become a Thing. It's not just AMD that could have carried out the analysis, anyone with enough curiosity could have done so, but no one did till now. That's supposedly the benefit of FOSS, but only if people actually go looking which is also its Achilles heel. In point of fact, I've run into so much "common wisdom" in the Linux development community that's turned out to be utterly wrong once I went looking (in the source), that I wonder if anyone really is looking outside of the code maintainers - and I'm not even a C developer. What's everyone else's excuse??

To me it didn't come off sounding like dumb luck to have found it. Are there even tools for profiling all nooks and crannys of the code to find these kinds of things?

[Vistaus]

Yet we still have people always asking "why do they have to remove old unused unmaintained cr@p from the source tree?!" like with DT_HASH. Lol.

Complexity. Learn about it, people.

I would love better performance on my AMD system, but I don't want to make the "don't-remove-old-stuff-from-the-kernel" gang mad.

[Vistaus]

I wonder how many such workarounds/quirks are in the Windows source code where hardware vendors have no or little insight. Lol.

Don't let the Windows fanboys of this forum hear you.

[RealNC]

I hope this gets backported to LTS. It would be interesting to test whether or not this is the source of the performance issues I have with some emulators ever since I upgraded from my old Intel system to a 3700X one. The emulators will run full-on for like 2ms or so to emulate one frame, then idle the rest of the time until the next emulated vblank. If I don't use GameMode to switch from the schedutil to the performance governor, I get sound dropouts and animation hiccups.

[Mitch]

Hopefully, this gets backported by Valve on the Deck or they use 6.0 soon. I imagine the Steam Deck could get a lot of benefit here too.

[NateHubbard]

I would love better performance on my AMD system, but I don't want to make the "don't-remove-old-stuff-from-the-kernel" gang mad.

It's fine, I make them mad every month or so.

[coder]

It seems Linux competition is so slow AMD didn't even notice such suboptimal performance.

It's not due to lack of competition. It's because AMD was probably in fire-fighting mode for a long time, as its software team was playing catchup and doing all the server support & enablement work, and only recently started getting into more expansive performance-tuning.

[Mahboi]

Horrid thought because of the necessary workload, but I wonder how much code clarity, speed and maintenance efficiency we'd have if we canned Linux and rebuilt a new OS from scratch with the experience Linux has given us. OpenVPN vs Wireguard style.

Yes yes, I'm just dreaming.

[coder]

I wonder how much code clarity, speed and maintenance efficiency we'd have if we canned Linux and rebuilt a new OS from scratch with the experience Linux has given us.

There are plenty of cases where you have a mostly compute-bound workload and a different OS wouldn't make much difference. There are others where you could probably get a multiple of performance, particularly if you radically redesigned the security architecture to reduce the amount of syscalls or certain overheads associated with paging.

Linux probably has a fair amount of gas left in the tank, but I think the profusion of cores & multithreaded workloads represents a new challenge that it hasn't fully taken onboard. In short, I think Linux relies to heavily on userspace threading for utilization of multiple cores, but that's not the only option.

Anyway, it's not that people aren't trying. How long has Google been working on Fuchsia? But Linux is going to be extremely difficult to displace, due to the amount of industry support behind it.