Memory benchmarks down since kernel 6.12.13-200.fc41.x86_64

After updating to kernel 6.12.13, I have noticed a drop in memory benchmarks and system micro stutters seemed to be slightly more frequent (mostly noticeable with mouse, moving windows or gaming). Running a benchmark like phoronix ramspeed has shown a decrease of 10-20,000 MB/s for various memory calculations. Unsure really how to diagnose this but booting with kernel 6.12.11 resolves the issue. Any further information I can provide, please let me know. This is a newly built system for me so I am not overly familiar with it as of yet. Performance for the most part seems unaffected other then the memory calculations and that slight stutter increase. I did update to the 6.12.15 kernel a few days back and so far while I feel the micro stutter is back to that of 6.12.11 at minimal, maybe even better, the memory benchmarks are still within that 10-20,000 MB/s decrease variation.

As you can see below I have 4 sticks of ram and have been slowly increasing clock and timings while trying to maintain maximum stability under high work loads. This is most likely why I even noticed it other then the micro stutters and some additional time with some compilations. Holding off on further adjustments as of now. Some initial research pointed that the micro stutters could be from Nvidia and Wayland which is disappointing as I was hoping to migrate sim racing to linux but with the stutter, it defeats the purpose.

Anyhow, just trying to learn and understand what might be going on. Maybe I can track something down for my gaming stutter as well. Appreciate any insight!

MSI MPG X870E CARBON WIFI
4 x 24GB DDR5 @ 6000MT/s
AMD Ryzen 9 9950X 16-Core @ 5.75GHz

Fedora Linux 41 (Workstation Edition)
6.12.13-200.fc41.x86_64
6.12.15-200.fc41.x86_64
GNOME Shell 47.4
Wayland

If you use default memory settings, no over clocking, what is the performance under each kernel?

If you memory has ecc (and I think it’s in all modules now at least internally) maybe the delay if recovery from bit errors.

With further testing I can confirm it doesn’t matter if it’s overclocked or default. I’ve tested as low as 3600MT/s and kernels 6.12.13 and 6.12.15 consistently show a 15-26% performance loss through the various calculations performed.

Motherboard doesn’t support ecc and my memory is also non-ecc.

I also was able to test this with a secondary machine. I can not replicate it but the machine was also x370 based and DDR4. Only guess is something within the kernel or it’s dependencies has changed how it communicates with my hardware.

What do you use to benchmark the memory performance?

I’d like to see if I can duplicate your results.

Sorry I was rather vague when I mentioned it. I am using phoronix-test-suite, mainly ramspeed with all options and occasionally the memory suite which contains ramspeed and other tests.

It can either be installed via dnf or cloned from github, I’m using the git clone. It does have a few dependencies and some tests may as well.

phoronix-test-suite install ramspeed
phoronix-test-suite run ramspeed

Appreciate your interest and curious of your findings.

Since you’re able to reproduce the problem and you know the regression was introduced between 6.12.11 and 6.12.12, I think the best way to diagnose is brute force: bisect the kernel. You don’t have to be a software developer to do this, although it would help since building the Linux kernel is not entirely straightforward. The idea is build the commit halfway between .11 and .12, see whether it’s bad or good, and then repeat until you wind up at the culprit commit. Anybody who is able to reproduce the regression should be able to do this.

I had already pulled the sources and built the kernel with testing in mind, although reverting things as I went along. 6.12.12 was skipped so I can’t confirm it introduced the issue, 6.12.13 did for sure but I get what your saying. I was not familiar with git bisect though so thanks for that information. I’m currently six builds in with no luck as of yet. It’s not resolved in 6.13.4 either.

I have tracked this down to the following commits. Essentially the forcing of x86_sched_itmt_flags for PKG domain unconditionally. Building all affected kernels with these reverted resolves the lower benchmarks and restores memory performance.

c572fb94371d x86/topology: Use x86_sched_itmt_flags for PKG domain unconditionally
b8af5591f35f x86/cpu: Enable SD_ASYM_PACKING for PKG domain on AMD

Further research into this has led me to find a workaround without the need for a kernel rebuild.
Check if itmt is enabled.

cat /proc/sys/kernel/sched_itmt_enabled

Disable itmt if it is enabled.

echo "0" | sudo tee /proc/sys/kernel/sched_itmt_enabled

All is well again with the memory benchmarks. I suspect this may not be the actual problem and something may be bugged in the Intel Turbo Boost Max Technology Support but I’m just an enthusiast.

EDIT: lol, I don’t know how to use the forum with proper formating…

1 Like

Use in the menu the option for preformated text </>

for now i changed it for you.

Good job! Knowing exactly which commits introduced the problem will help a lot. Now you just need to get the attention of the right kernel developer. The kernel has some bug report documentation that should help…