The implication seems to be that other architectures are also soon to have SMT disabled by default. That would definitely hurt POWER, for example.
Also 64-bit Arm...
OpenBSD disables Intel's hyperthreading due to security concerns
71–80 of 158 posts
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#72They should make it easier to find the diff behind all openbsd emails. I can’t find this one.
Although not ideal, and there is likely an easier way to do it in full CVS (but i lack those skills), but you can always go to their Web CVS and manually check the files listed in the commit:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64...
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#73Earlier quoted context omitted.
I don't think the plan is to ever enable this in the comming few years. The current approach with a few tabs is much more memory efficient, which is why they've chosen it.
And it's a mistake. Just recently I noticed that when Firefox loads multiple tabs of the same wordpress site, it starts hanging not unlike Firefox always used to hang. That's likely because it groups all of those same site pages under one process. I've never experienced that with Chrome. This is why I hope Firefox eventually (ASAP) switches to one process per tab, too. I can handle the browser using an extra GB of RA…
Chrome does not use one process per tab. In fact, it does something very similar to what you say Firefox does.
http://dev.chromium.org/developers/design-documents/process-...
FWIW I do not have the problem you describe and I don't want Firefox wasting any more of my scarce memory, or for that matter, CPU.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#74Earlier quoted context omitted.
The contention would actually not be on a per-EU level, but one level higher up. The reservation station has a bunch (~5-8) of ports and typically multiple EUs are connected to one port. Can't use one port for two different things at the same time. Here's a simplified block diagram of a Skylake core: https://en.wikichip.org/wiki/intel/microarchitectures/skylak...
Thanks! Yeah figured I'd be wrong somewhere in there!
There's also some funkiness around the CPU cache, at least at one stage. If your two HT threads are working on the same data, there was a chance you'd get some great cache performance out of it. However the hyperthread when faced with a cache miss, can cause the cache to get evicted to be replaced with the data it needs. Under those circumstances, performance takes quite a nose dive as both threads are stomping over each other somewhat.
Hyperthreading can be a real mixed bag for performance, though generally good and a lot of engineering effort has gone in to making it shine. As ever it's strongly advisable that people benchmark real world conditions on a server, and it's worth giving a shot with hyperthreading turned on and off.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#75Re: OpenBSD disables Intel's hyperthreading due to security concerns
#76Earlier quoted context omitted.
> The reason is that two threads of the same program will often end up executing similar instruction streams Why is that bad?
Your processor has a certain number of execution units which can actually execute individual instructions, maybe like 4 floating point units, maybe 8 arithmetic ones, and maybe 1 that can do vector processing (these numbers are not real, but are like, good enough for sake of message). So the idea with SMT is that most of the time, lots of the execution units are unused because the thread a) isn't using them at all (e…
You are pretty much right. A couple of things to add: even hand optimized asm code wont be able to use all ports all the time with a single instruction steam; the biggest win for hyperthreading is filling the pipeline bubbles caused by memory loads out of L1 (there is only so mach that OoO scheduling can do on your average load)
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#77Earlier quoted context omitted.
So, you're saying because you think you've discovered one case where there might be a problem, Firefox should completely change their architecture? And you're saying this in a discussion which frequently mentions how extremely varied workloads are?
No, man. He said Firefox should change their architecture, and he gave some kind of example. After the way you seized on the word "typical", I kind of expected you to take words at face value. I didn't see any text to the effect that he thinks his say so is good enough. Also, you're the one frequently mentioning how varied workloads are, and you don't constitute the discussion. I'm going to go drink some cocoa to was…
Not intended as flame bait, sorry if that's how it comes across to you.
It just so happens that people complaining about Firefox doing it wrong is a pretty common thing in Firefox threads on HN. And they usually have an example where it's really unclear if it's a problem for more than them or not. But, usually, they have a lot of advice about what the Firefox team should do. Whereas the Firefox team has telemetry data from most of their users.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#78Earlier quoted context omitted.
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…
> workload dominated by non-local DRAM fetches, How often is that a polite way of saying "software that is inefficient"?
With most software, well most software is pretty inefficent and profits from HT. However there are a lot of reasons for that, writing in something interpreted because it is faster to develop and the software does not need to be very efficient in the first place would be one application. (Not to say that all Python/JS/etc is inefficient, just that software that needs to be efficient is precisely the kind were one would consider an unmanaged language.) Additionally, things like webservers or dbs often just don't know which piece of data they need next, simply because they don't know the next query, have a tendency to profit from HT, even though the software is hardly known for being inefficient.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#79Earlier quoted context omitted.
If you won't stop posting snarky one-liners we'll ban the account. https://news.ycombinator.com/newsguidelines.html
This comment finally put the puzzle pieces for why so many people seem to hate this website.
A) Whom? B) Why?
I can't see this flagged post, but the user in question has such quality comments as "hahahaha", "ouch", and "duhhh" -- most users here actually contribute to discussion, where as a few think this is reddit...
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#80Earlier quoted context omitted.
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…
> workload dominated by non-local DRAM fetches, How often is that a polite way of saying "software that is inefficient"?
I'm not sure there is a correlation. I can think of many situations in which non-local DRAM fetches are more efficient and I can think of many other situations where the opposite is true.
Trees or hashmaps which use non-local DRAM fetches can be more efficient than a brute force linear search through a continguous array given a sufficiently high enough number of elements.
At the same time continguous arrays can be significantly more efficient than linked lists which use non-local DRAM fetches.