Intel CPU performance-loss by security-patch?!?
Posted: Wed Jan 03, 2018 1:41 pm
Computer Chess Club
https://talkchess.com/
I read about this problem so time ago (KAISER patches to address a security problem related to the kernel being mapped into the address space of user processes), so this whole thing is not as secret and sudden as the article suggests it is.
Lol sure, if you are Amazon, or offering cloud services. On home machines ofc it will be possible. More than 50% of windows home machines are running cracked windows for god sake.syzygy wrote:On Windows and Mac there will likely be no way to disable the fix and its performance penalty.
The discussions at some IT forums made me confused.
It seems applications with lots of I/O incur the largest performance overhead, whereas purely computational tasks seem to be affected much less:ZirconiumX wrote:It's hard to judge what the slowdown is for chess, but I would imagine that due to page faults, this would result in a more significant slowdown the larger your hash tables are. Beyond that, I have no idea, as chess programs are largely user-space.
It is not the same, but 28% is the more accurate number here, at least for certain workloads.MikeGL wrote:The discussions at some IT forums made me confused.
The overhead, if I understand the published kaiser paper correctly,
is just around 0.28% and not 28%.
less than 1% overhead is not the same as 28%.
kernel developer wrote:KAISER will affect performance for anything that does system calls or interrupts: everything. Just the new instructions (CR3 manipulation) add a few hundred cycles to a syscall or interrupt. Most workloads that we have run show single-digit regressions. 5% is a good round number for what is typical. The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches. More details about possible performance impacts are in the new Documentation/ file.
This code is based on a version I downloaded from (https://github.com/IAIK/KAISER). It has been heavily modified.
The approach is described in detail in a paper[2]. However, there is some incorrect and information in the paper, both on how Linux and the hardware works. For instance, I do not share the opinion that KAISER has "runtime overhead of only 0.28%". Please rely on this patch series as the canonical source of information about this submission.
+1syzygy wrote:It is not the same, but 28% is the more accurate number here, at least for certain workloads.MikeGL wrote:The discussions at some IT forums made me confused.
The overhead, if I understand the published kaiser paper correctly,
is just around 0.28% and not 28%.
less than 1% overhead is not the same as 28%.
https://lkml.org/lkml/2017/10/31/884kernel developer wrote:KAISER will affect performance for anything that does system calls or interrupts: everything. Just the new instructions (CR3 manipulation) add a few hundred cycles to a syscall or interrupt. Most workloads that we have run show single-digit regressions. 5% is a good round number for what is typical. The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches. More details about possible performance impacts are in the new Documentation/ file.
This code is based on a version I downloaded from (https://github.com/IAIK/KAISER). It has been heavily modified.
The approach is described in detail in a paper[2]. However, there is some incorrect and information in the paper, both on how Linux and the hardware works. For instance, I do not share the opinion that KAISER has "runtime overhead of only 0.28%". Please rely on this patch series as the canonical source of information about this submission.