6 ms·
Of course SMT makes sense. Why would it not be? Article says that thats because ppl only count the threads in their "cpuinfo" output and get the wrong impressio
by altmind 7y ago
Of course SMT makes sense. Why would it not be? Article says that thats because ppl only count the threads in their "cpuinfo" output and get the wrong impression? Intel vulnerabilities are not SMT vulnerabilities per-se, they are side channel attacks on a specific SMT implementation.
- pjmlp 7y agoSome of them happen to be shared across all CPU vendors.
- kijin 7y agoWhich, now that they are known, can be fixed in future iterations of the technology. Just because Intel won't (or can't) fix their damn products doesn't mean that others won't.
- pjmlp 7y agoIt also doesn't mean others will fix their damn products. And even if they do, it doesn't mean anyone will replace existing hardware already deployed into production.
- kijin 7y agoSure, there's no guarantee, but that's not a particularly good reason to write off SMT wholesale. People who already have Intel CPUs in production aren't just going to turn off hyper-threading, either, regardless of what we say about whether or not future products should support it.
- ljhsiung 7y agoAlso want to add that to say "don't use SMT because it's insecure" is the same as saying "don't use a cache because it's insecure" or "don't use speculative execution". As a short-term fix, I would 100% agree that disabling SMT e.g. OpenBSD's approach is awesome and shows their security-consciousness. But to preach "disable SMT because it's too challenging" feels very lazy. Additionally, as you've said, it's still uArch dependent. For example-- the Fallout vulnerability (one of the MDS attacks) only worked on Intel machines, but not AMD+ARM, most likely due to the differences in how the two designs handled store-to-load forwarding on the store queues/buffers. The author seems to also value security over performance. I do as well. But the balance between performance and security is a fickle one, and I feel that "SMT is nonsensical" is a bit too much
- phkahler 7y ago>> Additionally, as you've said, it's still uArch dependent Intel would love for everyone to disable SMT regardless of vendor. That would help them with relative performance.
- AdrianB1 7y agoWhen you pay licenses per-CPU and SMT is doubling the cost with the licenses without doubling the performance, SMT does not make sense. For other cases, it makes. There is no universal use case for it.
- tyingq 7y agoThere's a persistent rumour that Oracle does this, but they don't. For example: "Amazon EC2 and RDS - count two vCPUs as equivalent to one Oracle Processor license" https://www.oracle.com/assets/cloud-licensing-070579.pdf https://www.oracle.com/assets/cloud-licensing-070579.pdf Is there a vendor that does count a hyperthread as a core for software licensing?
- rumanator 7y agoPlease don't cherry pick quotes. The full quote with the bit you left out is as follows: > Amazon EC2 and RDS - count two vCPUs as equivalent to one Oracle Processor license if hyper-threading is enabled, and one vCPU as equivalent to one Oracle Processor license if hyper-threading is not enabled. As you see, your own quote confirms that yes the rumors are true: Oracle does charge per CPU.
- tyingq 7y agoYeah, that's what I said. Oracle charges per core. I didn't cherry pick anything.