4 ms·
One datapoint: We run our production HFT machines with migrations=off. Latency at the microsecond level is highly critical, and these machines don't have any pu
by dcolkitt 6y ago
One datapoint: We run our production HFT machines with migrations=off. Latency at the microsecond level is highly critical, and these machines don't have any public facing interface.
This is obviously a niche case. But IMO, I can see similar calculus for other more mainstream use cases. I wouldn't turn migrations=off on a public facing web server. But if you have a cluster that does ETL data processing, it's probably CPU-bound and has very little externally exposed surface area. Arguably, even backend SQL servers can benefit, assuming the set of clients that directly access the dbase are tightly controlled and audited.
- ncmncm 6y agoAnother: we do not. Our code runs with exactly zero system calls once it has finished starting up, so we never execute the code affected by mitigations. When every cycle counts, wasting them in the kernel is not a good idea anyhow. So, isolcpus and kernel bypass FTW.
- londons_explore 6y agoHow many other "trade security for performance" options does Linux have? For example can you disable paging entirely and have all user code mix with kernel code as long as you trust all code not to segfault?