Do you get the exact same performance characteristics by ignoring the extra virtual cores as you would have gotten if you could actually disable hyperthreading in the CPU via the firmware setup? Or does it result in some CPU resources becoming unusable that would otherwise be usable if HT were truly disabled?
OpenBSD disables Intel's hyperthreading due to security concerns
21–30 of 158 posts
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#22Re: OpenBSD disables Intel's hyperthreading due to security concerns
#23So... 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…
Yeah, they are fairly risk-averse and not really performance oriented, so this decision feels pretty much in line with their practice.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#24> 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…
> The reason is that two threads of the same program will often end up executing similar instruction streams
Why is that bad?
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#25OpenBSD 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.
Yes, it's probably easier to exploit with hyperthreading, but does disabling hyperthreading stop the exploits?
No, it's just an incomplete solution and a minor setback at an enormous cost.
OpenBSD does these often, and it looks silly doing it.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#26OpenBSD finds yet another way to shoot themselves in the foot.
Sounds like it's a default towards the more secure, but they're not preventing the user from enabling it. Not sure what the issue is..
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#27Earlier quoted context omitted.
>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…
> The reason is that two threads of the same program will often end up executing similar instruction streams Why is that bad?
Taking a guess, but since they are running similar streams, they have similar loads at a specific time. Competition between main thread and hyperthread could hurt performance instead?
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#28Earlier quoted context omitted.
>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…
> The reason is that two threads of the same program will often end up executing similar instruction streams Why is that bad?
"both are using vector instructions (these registers are shared between the two hyperthreads)"
So I guessing GP meant there's going to be contention for those registers, and thus no speedup?
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#29Earlier quoted context omitted.
>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…
> The reason is that two threads of the same program will often end up executing similar instruction streams Why is that bad?
Different instruction streams use different registers. It’s like sharing a bathroom. I can shower while you brush your teeth. There’s more contention when we’re both trying to shower.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#30> 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…
In practice it sometimes is the case, though.
SMT/hyperthreading is complicated. If you have a workload dominated by non-local DRAM fetches, it's a huge win because when the CPU pipeline is stalled on one thread it can still issue instructions from the other.
If you have a workload dominated by L1 cache bandwidth, the opposite is true because the threads compete for the same resource.
On balance, on typical workloads, it's a win. But there are real-world problems for which turning it off is a legitimate performance choice.