6 ms·
Not everyone is running any untrusted code. If you're running (for example) a physics simulation, the mitigation doesn't gain you much.
by e1ven 8y ago
Not everyone is running any untrusted code. If you're running (for example) a physics simulation, the mitigation doesn't gain you much.
- w0utert 8y agoFortunately the performance of these kinds of CPU-bound workloads are almost completely unaffected by the mitigations, so you might as well enable them anyway.
- Filligree 8y agoOne of them is "Disable hyperthreading," which absolutely has a severe penalty.
- greglindahl 8y agoFor some workloads.
- germainelong 8y agoFor some workloads it is better to have hyperthreading disabled.
- gnufx 8y agoActually, I've seend benchmarks to the contrary. As usual with benchmarks, there's no useful data to understand them -- specifically not performance counter data. I've yet to see a good analysis and haven't been able to do it myself. Many large-scale computations actually aren't CPU-bound, except insofar as they spin in MPI; some do plenty of filesystem i/o, but at least with something like PVFS2, that can be just in user-space on the compute node.
- gnufx 8y agoThe sort of HPC clusters with which I'm familiar run plenty of what I'd call untrusted code, and are multi-access with arbitrary student users and not-infrequently-compromised credentials. That said, there seems to be a fairly small attack surface the way I'd set up compute nodes, even if they're not single-job/node; especially if maximum job times are a day or two. I probably wouldn't turn on the mitigations on compute nodes.