Benchmarking The Intel Performance Change With Linux FSGSBASE Support

[kcybulski]

Yes, I would like to see Zen performance with FSGSBASE

[tuxd3v]

Yes, I would like to see Zen performance with FSGSBASE

AMD Steamroller arch also support fsgsbase!
My kavery AMD A10-7800, at least supports it..

It would be interesting to compare performance with this arch..since it uses CMT I believe..

[TOMBOMBADIL]

Is there a reason for not measuring "WIP kernel + No mitigations" (other than time constraints for publishing the article)?

(And other than the complete irrelevance thereof since the two have nothing to do with each other)?
I think adding the one not-mitigated run to the test was a mistake already. You can't weight them against each other. It's not like you're going to say "Ok, now I switch on mitigations because thanks to FSGSBASE my system will remain as performant as I need it." The performance/security impact/trade-off remains exactly the same. FSGSBASE is just one of many performance improvements that make their way into the kernel all the time, and it's great to see the impact of it. But the mitigations/no-mitigation tests have nothing to do with the point of this article.

[TOMBOMBADIL]

Do you have the numbers necessary to back your claims?

The whole point of my argument is that no additional numbers are needed.
Or are you actually going to switch mitigations on in your kernel if FSGSBASE first increases the performance by the same amount? (in which case this article has everything you need doesn't it?) But that would be quite arbitrary.
Michael himself wrote "Granted, FSGSBASE patches plus an unmitigated kernel would likely yield even better performance." Which makes sense since FSGSBASE has nothing to do with the mitigations. So if comparing FSGSBASE to mitigations is relevant, then so is comparing it to latest mesa improvements, latest gcc improvements, the regression that affected steam games the other day and what not. But that's completely pointless as these things have nothing to do with each other and the goal is not to find the highest number of regressions you can build into your kernel without losing performance thanks to other arbitrary improvements... a regressions is always a regression even if something else gets faster due to another fix.
So I think, for FSGSBASE impact benchmarks, mitigations impact is irrelevant, and for mitigations impact benchmarks, FSGSBASE is irrelevant. It's not even comparing apples with pears, it's comparing apples with Durian fruit...
So just check once in a while the impact of mitigations on the latest kernel to see if the regression has reduced enough for you to be worthwhile to switch on (Which I agree, is interesting to track, just not relevant for an article called "Benchmarking The Intel Performance Change With Linux FSGSBASE Support".

[starshipeleven]

What about older chips (like ivy bridge) before any hardware mitigations? I assume modern Intel chips offset the performance hit from vulnerabilities with new hardware workarounds, something older chips can't do.

Has any Intel chip shipped with hardware mitigations yet? Afaik it's only microcode (aka low-level software mitigation)