Ouch. Huge hit for performance.
OpenBSD disables Intel's hyperthreading due to security concerns
11–20 of 158 posts
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#12Ouch. I will say though, Hyper-Threading is a lot less valuable these days than it was when it was first introduced (except for the few dual core CPUs still available). When you have four-six-eight or more cores, there's less value in doubling that number. The gain is lower.
On the other side, a hyperthreaded CPU used to be about 10 - 30% gain, but in tests I've ran on recent hardware (HP DL380 Gen 10) hyperthreading gives around 70% more performance (the test I used was running pigz [parallel gzip] on a large file).
That's a great example of how hyperthreading's performance effects are extremely workload dependent.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#13OpenBSD finds yet another way to shoot themselves in the foot.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#14Ouch. Huge hit for performance.
From the commit message, it sounds like that might not necessarily be the case: "Note that SMT doesn't necessarily have a posive effect on performance;
it highly depends on the workload. In all likelyhood it will actually
slow down most workloads if you have a CPU with more than two cores."
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#15OpenBSD finds yet another way to shoot themselves in the foot.
I'd say it's probably closer to:
> OpenBSD finds yet another way to harden their OS.
This is a conscious choice to disable something that could potentially allow for an entire class of security vulnerabilities. I suppose a decent analogy could be they chose to amputate a damaged foot before it had time to turn gangrenous.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#16[deleted]
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#17[deleted]
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#18OpenBSD finds yet another way to shoot themselves in the foot.
By continuing a security-first mindset that they've been establishing for decades?
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#19So... they "strongly suspect" (but don't know and haven't shown) there may be a Spectre-class bug enabled by current HT implementations and improving their scheduler is hard, so they'll pre-emptively disable HT outright on Intel CPUs now and others in the near future?
I'm not an OpenBSD user (and glad for it, if this is anything to go by), but I'm curious - is this really how they operate, or does this decision stand out?
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#20> We really should not run different security domains on different processor threads of the same core. Unfortunately changing our scheduler to take this into account is far from trivial. This suggests a long-term compromise solution where threads within a process can use hyperthreading to share a core, but threads in different processes can't. Given that hyperthreads share L1 cache, this might also be better for perf…
>This suggests a long-term compromise solution where threads within a process can use hyperthreading to share a core, but threads in different processes can't. Given that hyperthreads share L1 cache, this might also be better for performance.
Intuitively this may sound logical, however in practice it's often not the case. For many workloads putting two threads of the same program on a core ends up being worse than co-locating with threads from different programs. The reason is that two threads of the same program will often end up executing similar instruction streams (a really good example is when both are using vector instructions (these registers are shared between the two hyperthreads)).