On Mon, 19 Nov 2018, Ingo Molnar wrote:
This was marked for stable, and honestly, nowhere in the discussion did I see any mention of just *how* bad the performance impact of this was.
Yeah. This was an oversight - we'll fix it!
When performance goes down by 50% on some loads, people need to start asking themselves whether it was worth it. It's apparently better to just disable SMT entirely, which is what security-conscious people do anyway.
So why do that STIBP slow-down by default when the people who *really* care already disabled SMT?
I think we should use the same logic as for L1TF: we default to something that doesn't kill performance. Warn once about it, and let the crazy people say "I'd rather take a 50% performance hit than worry about a theoretical issue".
Yeah, absolutely.
We'll also require performance measurements in changelogs enabling any sort of mitigation feature from now on - this requirement was implicit but 53c613fe6349 flew in under the radar, so it's going to be explicit an explicit requirement.
Do you already have an idea whether you'd proceed with Tim's patchset for current cycle? If so, great as far as I am concerned. If not, I'll send a patch that switches this to opt-in via kernel cmdline (+boot-time warning if not mitigated).
Thanks,