VM Performance Showing Mixed Impact With Linux 4.15 KPTI Patches

[sthalik]

So turning off KPTI is the new overclocking? Good for anyone hating heavy heat in the summer. Run stock clock but disable KPTI.

Look for more syscall-heavy tests. The pure-computation workloads aren't affected at all, or not significantly.

Another "fix" could be busy-looping for a small amount of cycles in the syscall entry point, but significant enough to defeat the RDTSC side channel attack.

[Michael]

Look for more syscall-heavy tests. The pure-computation workloads aren't affected at all, or not significantly.

Unless running in a VM.

[sthalik]

Unless running in a VM.

I'm sorry, actually the 5.5% slowdown is significant.

While I'm at it, could you use the same compiler and version for the next Linux+BSD tests?

[oibaf]

Interesting read about performance drops: https://access.redhat.com/articles/3307751

BTW this was made accessible now. Also upgraded the maximum performance drop from 12% to 19%.

[linuxgeex]

there is a simple way to fix the spectre bug on amd cpus and other cpus:

you just but system processes theats with ROOT privileges on one cpu core and processes without Root privileges on another cpu core.

sure this does not work for single-core systems but on modern cpus with many cores you can just do it like this.

you maybe lose a lot of performance because of this but different cpu core makes you "save"

Yes I suggested that as one possible fix too, but you need to recognise that it will have a large performance impact, perhaps even worse than disabling branch prediction, because it will require effectively re-enabling the BIG_SMP_LOCK from the early days, which the kernel developers worked for a decade to remove.

[epigramx]

I guess this forum might be interested in my results on a demanding multithreaded game running with wine:

https://www.reddit.com/r/cemu/comments/7opxa8/my_cemu_results_on_linux_beforevsafter_the_patch/

tl;dr: Low-latency preemption model reduced the impact significantly but also the impact is not significant unless there is multithreading.

[caligula]

Let's hope your optimism is warranted. So, if not disabling branch prediction and speculative execution, how do you propose mitigating Spectre?

Disabling those features will have a huge perf effect. If the whole CPU is tuned for OoOE, it won't perform well as an in-order processor. This link discusses branch prediction. Expect up to 6x slowdown without it. https://stackoverflow.com/questions/...unsorted-array

[caligula]

and still better than have no security fix for spectre

everyone think meltdown is the hard bug but they fixed it already but spectre 1/2 maybe can not be fixed...
using different cpu cores are maybe the only way who knows it for sure?

In some cases reorganizing your code and limiting low level access might mitigate the issue well enough. Cases like javascript execution. It's not a single big issue that behaves the same everywhere.

[linuxgeex]

why you need the big lock?

in my point of view if you can fill every core with usefull tasks you maybe have no impact in performance at all.

and still better than have no security fix for spectre

everyone think meltdown is the hard bug but they fixed it already but spectre 1/2 maybe can not be fixed...
using different cpu cores are maybe the only way who knows it for sure?

Running the kernel on a single core, and userspace on other cores, basically in messaging mode like DragonFly, would only solve your problem if the kernel handled one request at a time to prevent speculative effects due to kernel re-entrancy. Hence the big SMP lock - only one request at a time. Which is fine most of the time. It's only really bad when for example you have a slow storage device and everything has to wait while the kernel polls it. When the system hits 90% syswait then userspace is throttled to 10% performance if it depends on a lot of syscalls. And also having the kernel on a single thread means no SMP for RAID or for multiple network interfaces, multiple GPUs... that would utterly crush the server industry.

There are some really brilliant fixes coming. Linus and various Google, Redhat, SuSE, and Intel/ARM/AMD developers are working on a combination of microcode changes to help gate speculation, and kernel/compiler changes to make use of them, and the net result will be that speculation is reduced in critical sections (not CRITICAL SECTIONS, that's another topic, lol) of the code, effectively pushing the attack window outside the speculation window.

I'm really relieved that at least the cloud will be protected soon and with a small performance impact. What concerns me now is the 10B devices that are not receiving regular security updates, that are still easy to compromise... if you remember the state of the Internet when the '95/'98/XP boxen were getting rampantly hijacked and operating in large botnets ("NET.sky" etc...) that was kindergarten compared to the problems we're going to face with all the unpatched connected devices there are now. :-( But at least we will be able to trust our purchases of the last year and the cloud services, soon. Fingers crossed the internet isn't DDOS's too badly by the botnets.

[linuxgeex]

Disabling those features will have a huge perf effect. If the whole CPU is tuned for OoOE, it won't perform well as an in-order processor. This link discusses branch prediction. Expect up to 6x slowdown without it. https://stackoverflow.com/questions/...unsorted-array

The good news is that they're working in gating techniques to filter/disable speculation where Spectre presents a risk, and so far these techniques are proving effective and don't have the sort of massive impact that disabling deep branch prediction would. That 6x is what may happen if they disabled it entirely. They don't need to disable it entirely. They only must reduce the depth of the speculation window to the point that it can't get any malicious work done. NUMA systems have much deeper speculation windows. ThreadRipper/EPYC and IBM POWER8 and POWER9 are probably going to suffer the most, because they have the highest cross-core access latencies, and those contribute to large speculation windows.