AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR

[scorpio810]

Opcache seems to work nice here , i checked compilation time and I don't saw any performance impact.

[duby229]

Opcache seems to work nice here , i checked compilation time and I don't saw any performance impact.

Yeah, It'll get benchmarked sooner or later on variety of loads. It's good to hear first hand experience, would you be willing to run some PTS benches with it toggled on and off?

[scorpio810]

I Build a mxe Qt5 cross-compilation environment in a loop for see if segfault or not.

https://community.amd.com/message/2817125#2817125

https://community.amd.com/message/2817165#2817165

Now I try other RAM sticks F4-2400C15-16GVR -> BLS8G4D26BFSC.16FBR2

Sorry but i 'm very busy.

[keantoken]

What is the best way to know if you have this bug, and that it is not a different bug?

[duby229]

What is the best way to know if you have this bug, and that it is not a different bug?

kill-ryzen.sh

https://github.com/suaefar/ryzen-test/blob/master/kill-ryzen.sh

[bridgman]

kill-ryzen.sh
https://github.com/suaefar/ryzen-tes.../kill-ryzen.sh

... and watch out for ramdisk-related problems. Apparently 16GB is not enough to run 16 threads so you either need to reduce the # of threads (eg ./kill-ryzen.sh 4) or edit the script to run without ramdisk (so USE_RAMDISK=false).

Each parallel buildloop has a folder with a build log (eg /mnt/ramdisk/< I forget > /buildloop.d/loop-NN/build.log - when you have a failure check to see if the problem was a segfault or something boring like out-of-space on ramdisk or running out of memory because the ramdisk sucked it all up.

Finally, if you are lucky enough to have an Epyc box remember that zram is not particularly NUMA-friendly and will often cause problems. Might also apply to TR with "local memory" option selected. I know I got to play on a TR box with a terabyte of RAM and everything ran fine, but I don't know if the memory model was set to Local or Distributed (sorry, I didn't know about the option at the time).

[Funks]

What is the best way to know if you have this bug, and that it is not a different bug?

Don't want to install Linux on HDD? Just run the following for 12 hours..

https://www.reddit.com/r/Amd/comments/6rwggi/ryzen_build_loop_compile_failures_under_linux/

[Funks]

Finally, if you are lucky enough to have an Epyc box remember that zram is not particularly NUMA-friendly and will often cause problems. Might also apply to TR with "local memory" option selected. I know I got to play on a TR box with a terabyte of RAM and everything ran fine, but I don't know if the memory model was set to Local or Distributed (sorry, I didn't know about the option at the time).

On RYZEN - It would be weird if ZRAM has issues, if so Linux cache disk block would have problems as well. Compiling on ZRAM is a good thing for these tests as it's actually making the CPU do even more work.

[Khudsa]

The last bios update (807) from asus on the prime x370-pro motherboard has the opcache option. I have disabled it and have the kill-ryzen.sh running for several hours and no segfaults.

bridgman what does this option do? What is the performance penalty? There are other consequences by disabling the opcache?

Thanks,

edit: this also means that some cache is damaged on the cpu?

[Funks]

The last bios update (807) from asus on the prime x370-pro motherboard has the opcache option. I have disabled it and have the kill-ryzen.sh running for several hours and no segfaults.

it's a major performance feature of Ryzen, 6% performance drop on benchmarks when it's disabled. When OpCache is enabled, does the test fail for you? If so, get your chip RMA'd if that's the only setting you changed and it started working. You got one of the "marginal" chips.