Linux 6.2's Call Depth Tracking Helps Recover Lost Performance On Intel Skylake CPUs

[phoronix]

Phoronix: Linux 6.2's Call Depth Tracking Helps Recover Lost Performance On Intel Skylake CPUs

When the Retbleed security vulnerability was introduced earlier this year mitigating it for Intel Skylake and Skylake-derived CPU cores required imposing Indirect Branch Restricted Speculation (IBRS) that further tanked the out-of-the-box performance for these aging Intel CPUs. But being introduced now with Linux 6.2 is a new mitigation technique named Call Depth Tracking that is helping recover some of that lost performance and in turn extending the usefulness of the Skylake-derived processors still in service.

https://www.phoronix.com/review/skylake-retbleed-stuff

[coder]

with Linux 6.2 the IBRS mitigation is still the default for Skylake CPUs, but Call Depth Tracking when built into the kernel can be easily enabled with the "retbleed=stuff" boot option.

What's the likelihood of retbleed=stuff becoming the default, in a future release? Or has that basically been ruled out?

[milkylainen]

While it indeed does recover some lost performance,
it's still in the category of "performance horror show".

[milkylainen]

What's the likelihood of retbleed=stuff becoming the default, in a future release? Or has that basically been ruled out?

On a side note to defaults,
I built my kernel with CONFIG_SPECULATION_MITIGATIONS = n to test disabling it altogheter.
"If you say N, all mitigations will be disabled"
And I'm still getting a lot of speculation mitigation crud enabled in my kernel.

[ 0.106330] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[ 0.106330] Spectre V2 : Kernel not compiled with retpoline; no mitigation available!
[ 0.106330] Spectre V2 : Vulnerable
[ 0.106330] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
[ 0.106330] Spectre V2 : Enabling Restricted Speculation for firmware calls
[ 0.106330] RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!
[ 0.106330] RETBleed: Vulnerable
[ 0.106330] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
[ 0.106330] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
[ 0.106330] MDS: Mitigation: Clear CPU buffers
[ 0.106330] MMIO Stale Data: Mitigation: Clear CPU buffers
[ 0.106330] SRBDS: Mitigation: Microcode

So I'm left wondering wth that knob actually does.

[stormcrow]

While it indeed does recover some lost performance,
it's still in the category of "performance horror show".

And yet it's still perfectly adequate for general desktop usage if you don't care about synthetic benchmarks. Pretty much should tell people something right there. Desktop CPUs are largely in the same realm of "good enough" for most cases just like smart phones and have been for years.

[coder]

And yet it's still perfectly adequate for general desktop usage

This is not limited to desktops. In fact, you could simply disable mitigations at minimal risk to yourself (depending on which software you run & where you get it), on a simple desktop machine.

For cloud users, CPU performance = $$$. For developers of realtime systems, performance degradation caused by mitigations can result in existing hardware becoming non-viable, or requiring that its capacity be de-rated.

Even for the simple desktop user, every year software & the web grow more complex. The source trees I'm building take longer and longer, as languages grow more complex and compiler optimizers grow more sophisticated and ambitious. There's also increasing use of static analysis, for finding bugs and potential vulnerabilities. So, the same machine is already becoming less capable, even before picking up these performance-robbing mitigations.

if you don't care about synthetic benchmarks.

I count 10 different apps and libraries among these tests that aren't merely synthetic. All of them were impacted by mitigations.

Desktop CPUs are largely in the same realm of "good enough" for most cases just like smart phones and have been for years.

Please don't tell us whether we should care about this. The beauty of having actual data from a somewhat diverse set of tests is that we can decide, for our own purposes, whether or not it's relevant.

If you don't care about performance-robbing mitigations, I'm happy for you.

[Namelesswonder]

On a side note to defaults,
I built my kernel with CONFIG_SPECULATION_MITIGATIONS = n to test disabling it altogheter.
"If you say N, all mitigations will be disabled"
And I'm still getting a lot of speculation mitigation crud enabled in my kernel.
So I'm left wondering wth that knob actually does.

The text is old so it doesn't actually cover all mitigations, and only covers the mitigations that require to be compiled in, like retpoline.
If you want to stop all mitigations from being applied then you need to add mitigations=off to the kernel command line.

[milkylainen]

The text is old so it doesn't actually cover all mitigations, and only covers the mitigations that require to be compiled in, like retpoline.
If you want to stop all mitigations from being applied then you need to add mitigations=off to the kernel command line.

That explains a lot, thanks.

[bug77]

What's the likelihood of retbleed=stuff becoming the default, in a future release? Or has that basically been ruled out?

I'm guessing pretty high, but first it has to prove itself.

While it indeed does recover some lost performance,
it's still in the category of "performance horror show".

You have just been given the numbers. Is 11% penalty really a horror show for you?

[Developer12]

It's taken a long time for this to come to fruition. I remember reading about RSB stuffing patches for skylake in january of 2018: https://lwn.net/Articles/744287/ with the work popping up again in spring of that year. It seems IBRS' horror show has been good enough for everyone in the meantime.