Following Retbleed, The Combined CPU Security Mitigation Impact For AMD Zen 2 / Ryzen 9 3950X

[RealNC]

I believe defaults but with retbleed=off is the go-to config for home PCs. It would have been nice to see that specific test, as the retbleed mitigation doesn't seem that useful for that use case.

[birdie]

Birdie, seriously, educate yourself before spouting off. There's plenty of Linux commercial games available on Steam and GOG including those often overrated "AAA" published games.

Otherwise... yeah Spectre mitigations usually don't affect game performance very much... however, big caveat. No one has thoroughly explored what security problems GPUs have brought to the table beyond attacking the drivers, either.

Educate myself on what? That there are literal idiots on Phoronix? I've always known that.

I said "There are almost no native AAA games for Linux" - that's a fact.
I said "Most rare Linux games are Indies" - that's a also fact.

Proton/Wine/DXVK/Console emulators - are not Linux games. Period.

[milkylainen]

Horror show...

[Anux]

At 4K encoding it can scale better to higher core counts.

No errors ib labeling, it's all automated.

Ok thanks, I thought of an strange error in the automation. I'm still baffled by this extreme outlier. I will try some encoding tests on my ryzen and see if I can reproduce this.

[CochainComplex]

You only run local trusted verified code? There's zero need for mitigations.

You run someone else's code, i.e. JS? Enable them. You have a shared environment, i.e. you provide shared hosting? Enable as much as humanly possible or/and stick virtual guests to certain physical cores, so that different VMs always ran on their own dedicated cores.



Triple A games are normally GPU bound. Older games already run fast enough, it doesn't matter if mitigations are on or off. Just a waste of time. Lastly, there are basically no games for Linux aside from rare Indies.

I agree with the first part but I dissagree with the later part. Before Retbleed I have had mitigations always on but since then I have switch them off on my gaming rig (Zen2). Depends on the game. But usually at least 10-15% more fps throughput and more importatnt lower latencies. difficult to measure. So yes from the evidence leed point of view it could be placebo. However considering the price of a higher tier cpu+gpu config you cant argue that this is neglicable. Especially if you have to consider your budget. Besides all benchmarks show a strong evidance that at least(!) a small effect 5-10% is to be expected for any scenario with mittigations=off.

[FPScholten]

Ok thanks, I thought of an strange error in the automation. I'm still baffled by this extreme outlier. I will try some encoding tests on my ryzen and see if I can reproduce this.

I have a pretty old haswell based system, 4 cores 8 threads. I also do video encoding and surely when encoding 720p about 50% cpu capacity is used for SVT encoding. When encoding 1080p it is about 90% and anything above that will use 100% cpu capacity.
But more interesting, how are the various encoding parameters, transcoding significantly speeds up with tiling, but by default this is not enabled. Tiling makes better use of SMT when encoding one video to only one output, the default settings are better suited for encoding multiple video's simultaneously, or doing multiple encodes of the same video (for streaming in various resolutions for example)

[Anux]

I have a pretty old haswell based system, 4 cores 8 threads. I also do video encoding and surely when encoding 720p about 50% cpu capacity is used for SVT encoding. When encoding 1080p it is about 90% and anything above that will use 100% cpu capacity.

Yes you're right, but that doesn't explain the outlier. The 3950X has 16 cores, if less than 4 are used the scheduler should not use SMT-threads. Unless Linuxxx is right about the scheduler.

[schmidtbag]

I thought this was only exploitable from direct physical access? Where do we draw the line where we don't take every such problem so seriously?

[Linuxxx]

Yes you're right, but that doesn't explain the outlier. The 3950X has 16 cores, if less than 4 are used the scheduler should not use SMT-threads. Unless Linuxxx is right about the scheduler.

Of course I'm right...

Facts aside, here's more anecdotal evidence that schedutil is an embarrassment for Linux (the kernel):

Recently, before retiring my Intel Core 2 Duo E8400, I used it to compress a couple of videos I hadn't watched in ages.

Just to give my following observation some context:

The E8400 only has two clockspeeds it can alternate between, namely exactly 2 & 3 GHz; nothing in-between mind you!

Out of curiosity, I wanted to see how schedutil would behave when it has to decide between only two binary choices while encoding.

And what an unexpected surprise, schedutil would only saturate the dual-core CPU to about 85%, regularly alternating between 2 & 3 GHz.

The performance governor maintained 100% saturation all the time, of course!

And since not a single Linux kernel developer/hacker seems interested in working on schedutil anymore, maybe outright dropping it is the best path forward for Linux?

[Anux]

Of course I'm right...

probably. I couldn't reproduce this behavior but I have only 8 Zen+ threads on a monolithic die and also a different kernel.

And what an unexpected surprise, schedutil would only saturate the dual-core CPU to about 85%, regularly alternating between 2 & 3 GHz.

The performance governor maintained 100% saturation all the time, of course!

I also never saw any reason to use anything different than perf gov, it's the fastest and most power efficient (on most CPUs).