Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not everyone is running any untrusted code. If you're running (for example) a physics simulation, the mitigation doesn't gain you much.


Fortunately the performance of these kinds of CPU-bound workloads are almost completely unaffected by the mitigations, so you might as well enable them anyway.


One of them is "Disable hyperthreading," which absolutely has a severe penalty.


For some workloads it is better to have hyperthreading disabled.


For some workloads.


Actually, 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.


The 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.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: