The AMD Zen 2 / Zen 3 Performance Fix For Linux 5.11 Has Landed

[gardotd426]

So um, anyone wanna explain why this patch is causing my 5800X's core frequency to be reported as 6GHz? Yes. Seriously.

[gardotd426]

https://browser.geekbench.com/v5/cpu/6466982

Base Frequency: 6.0 GHz.

cat /proc/cpuinfo | grep -i mh
cpu MHz : 6004.296
cpu MHz : 5544.140
cpu MHz : 4412.129
cpu MHz : 5239.843
cpu MHz : 5083.984
cpu MHz : 5852.148
cpu MHz : 6004.296
cpu MHz : 5391.992
cpu MHz : 6004.296
cpu MHz : 5544.140
cpu MHz : 5700.000
cpu MHz : 5239.843
cpu MHz : 5083.984
cpu MHz : 5852.148
cpu MHz : 5000.680
cpu MHz : 5391.992

Wtf.

[gardotd426]

Yeah I've confirmed at this point that this patch breaks shit on Zen 3. Base clock is reported as 6.0GHz. /proc/cpuinfo and sysfs also both report core frequencies of 5.9-6.1 GHz. The original patch that was turned down and replaced did NOT have this issue. I reported it, the maintainer gave me an additional patch to try and work around the issue, and that patch forced clock speeds to run at 2.2 GHz, no matter what. I could set the governor to performance, I could manually set speeds, I could give it whatever load and nothing, it was locked to 2.2, and this time it was *actually* locked at that speed, it wasn't misreporting. Performance TANKED.

[Michael]

Yeah I've confirmed at this point that this patch breaks shit on Zen 3. Base clock is reported as 6.0GHz. /proc/cpuinfo and sysfs also both report core frequencies of 5.9-6.1 GHz. The original patch that was turned down and replaced did NOT have this issue. I reported it, the maintainer gave me an additional patch to try and work around the issue, and that patch forced clock speeds to run at 2.2 GHz, no matter what. I could set the governor to performance, I could manually set speeds, I could give it whatever load and nothing, it was locked to 2.2, and this time it was *actually* locked at that speed, it wasn't misreporting. Performance TANKED.

What CPU? Is your CPU overclocked?

Edit: at least from posts above looks to be 5800X? I can try with my 5800X tomorrow, but presumably is either something odd with mobo or is your system overclocked? (Right, not to 6GHz but wondering if something there is going wonky.)

[gardotd426]

Nope. Just using XMP, PBO and Core Optimizer (yes, I know XMP and PBO are technically not stock but they're not manual overclocking either). It's an X570 Taichi which has always shown everything perfectly and is probably one of the more commonly used X570 boards on Linux because it's compatibility is so good.

Like I said, the original patch you reported on works great and doesn't show this behavior. And yeah I know it's not actually running at 6 GHz because there's no way in hell (plus benchmarks are identical to when it's running at 4.7 all-core), but with the attempted "fix" patch clocks *are* actually locked to 2.2, so that's obviously unacceptable.

I'm on Agesa 1.2.0.0 as well, so I'm on the best Zen 3 BIOS/Agesa out there.

I've never seen anything remotely like this before on my 3200G, 2600X, 3600X, 3800X, or 5800X.

I went back to the previous patch that got turned down and replaced, and it's reporting:

cpu MHz : 3800.000
cpu MHz : 3800.000
cpu MHz : 3800.000
cpu MHz : 4495.531
cpu MHz : 3800.000
cpu MHz : 3800.000
cpu MHz : 3800.000
cpu MHz : 3800.000
cpu MHz : 3800.000
cpu MHz : 3800.000
cpu MHz : 3800.000
cpu MHz : 4312.464
cpu MHz : 3800.000
cpu MHz : 4891.525
cpu MHz : 4401.037
cpu MHz : 3800.000

in /proc/cpuinfo and

4294146
4763182
3920731
3914652
4732087
3893010
3946012
3950378
4639291
4418631
4164564
4264474
4204292
4866377
4732149
4179739

in sysfs.

Which works the same as 5.10 and all previous 5.11 release candidates (I've ran every single one).

[gardotd426]

What CPU? Is your CPU overclocked?

Edit: at least from posts above looks to be 5800X? I can try with my 5800X tomorrow, but presumably is either something odd with mobo or is your system overclocked? (Right, not to 6GHz but wondering if something there is going wonky.)

So I reported it to Rafael, and he gave me a patch to test, and the patch forced all clocks to stay locked at 2.20GHz no matter what (and yes they actually were at 2.20, it wasn't misreported), turns out there was an error in that patch, so he gave me an updated one to put on top of his other two commits (the ones that caused Zen 3 to report speeds of 6 GHz) and everything is now in working order again, so it does seem there was something wrong with those initial two commits, at least for Zen 3. The errors were showing in /proc/cpuinfo, sysfs, cpupower, and everywhere else you could think of. They're gone now after applying his patch from today.

[bosjc]

`schedutil` should probably be in the title, because like this it seems it's something to be excited about, where I'm guessing many don't use schedutil yet because of its still poorer performance.

Yeah - does this only effect schedutil? Or would performance/etc still see a bump. Last round of benchmarks seemed to still have schedutil behind performance/ondemand.

[gardotd426]

Yeah it's only schedutil, I always use performance so I never really cared about this, that is until the "fix" for the issue broke frequency reporting on Zen 3, but it's been fixed now (idk if it's made it upstream but I reported it and tested out the patches and they did fix the issue and he said he would send it)

[intelfx]

So I reported it to Rafael, and he gave me a patch to test, and the patch forced all clocks to stay locked at 2.20GHz no matter what (and yes they actually were at 2.20, it wasn't misreported), turns out there was an error in that patch, so he gave me an updated one to put on top of his other two commits (the ones that caused Zen 3 to report speeds of 6 GHz) and everything is now in working order again, so it does seem there was something wrong with those initial two commits, at least for Zen 3. The errors were showing in /proc/cpuinfo, sysfs, cpupower, and everywhere else you could think of. They're gone now after applying his patch from today.

What/where exactly is the patch?

And yeah, I sort of see how it became an issue. It probably takes the hardware-reported max boost freq, multiplies it by nominal_perf/100, and that becomes the software-reported max freq. While in reality the hardware-reported max boost freq is the actual max boost freq, and the nominal_perf abstract scale maps to the range from max boost freq down to some unspecified point below it rather than the other way around.

Can you point me to the discussion?

[gardotd426]

What/where exactly is the patch?

And yeah, I sort of see how it became an issue. It probably takes the hardware-reported max boost freq, multiplies it by nominal_perf/100, and that becomes the software-reported max freq. While in reality the hardware-reported max boost freq is the actual max boost freq, and the nominal_perf abstract scale maps to the range from max boost freq down to some unspecified point below it rather than the other way around.

Can you point me to the discussion?

It's already been merged into linux-next.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=538b0188da4653b9f4511a114f014354fb6fb7a5

There's a link there to the bugzilla bug report, but it's just the original one about the poor performance mentioned in these articles on Phoronix, the discussion about this happens toward the end.