Slashdot Mirror
Two Linux Kernels Revert Performance-Killing Spectre Patches (phoronix.com)
Friday Greg Kroah-Hartman released stable point releases of Linux kernel 4.19.4, as well as 4.14.83 and 4.9.139. While they were basic maintenance updates, the 4.19.4 and 4.14.83 releases are significant because they also reverted the performance-killing Spectre patches (involving "Single Thread Indirect Branch Predictors", or STIBP) that had been back-ported from Linux 4.20, according to Phoronix:
There is improved STIBP code on the way for Linux 4.20 that by default just applies STIBP to SECCOMP threads and processes requesting it via prctl() but otherwise is off by default (that behavior can also be changed via kernel parameters). Once that code is ready to go for Linux 4.20, we may see it then back-ported to these stable trees.
Aside from reverting STIBP, these point releases just have various fixes in them as noted for 4.19.4, 4.14.83, and 4.9.139.
Last Sunday Linus Torvalds complained that the performance impact of the STIPB code "was clearly way more expensive than people were told," according to ZDNet: "When performance goes down by 50 percent on some loads, people need to start asking themselves whether it was worth it. It's apparently better to just disable SMT entirely, which is what security-conscious people do anyway," wrote Torvalds. "So why do that STIBP slow-down by default when the people who *really* care already disabled SMT?"
There is improved STIBP code on the way for Linux 4.20 that by default just applies STIBP to SECCOMP threads and processes requesting it via prctl() but otherwise is off by default (that behavior can also be changed via kernel parameters). Once that code is ready to go for Linux 4.20, we may see it then back-ported to these stable trees.
Aside from reverting STIBP, these point releases just have various fixes in them as noted for 4.19.4, 4.14.83, and 4.9.139.
Last Sunday Linus Torvalds complained that the performance impact of the STIPB code "was clearly way more expensive than people were told," according to ZDNet: "When performance goes down by 50 percent on some loads, people need to start asking themselves whether it was worth it. It's apparently better to just disable SMT entirely, which is what security-conscious people do anyway," wrote Torvalds. "So why do that STIBP slow-down by default when the people who *really* care already disabled SMT?"
When using the kernel with with the spectra/meltdown fix my 10 year ThinkPad W500 with core 2 duo P9700@2.8GHz {32k-L1, 6M-L2} went from a performance of a 2017 i3 to a performance of less than a 2008 Pentium 4. The specra/meltdown fix flushes the cache every cycle so that large 6M-L2 becomes useless.
Also take into account that this comment is mostly targeted at virtualized server loads, not desktop computing. While there are these scenarios of "JavaScript in the browser steals your keys", the actual threat is "VM1 steals the keys of VM2", for various reasons. My prediction is that SMT will basically be dropped by CPU manufacturers. AMD was never very keen on it and Intel is currently reversing their propaganda on how great it is.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.