Intel CPU performance-loss by security-patch?!?

[pohl4711]

https://www.theregister.co.uk/2018/01/0 ... sign_flaw/

https://www.postgresql.org/message-id/2 ... narazel.de

[syzygy]

https://www.theregister.co.uk/2018/01/0 ... sign_flaw/

https://www.postgresql.org/message-id/2 ... narazel.de

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.

It seems Intel processors will be slowed down by a lot. AMD processors are not affected.

So this is good news for AMD.
It is even better news for Intel: after a 30% slowdown of old and current Intel processors, many users will find it necessary to upgrade to fixed Intel cpus. This is Apple^2.

Apparently it will be possible to disable the fix and its heavy performance penalty on Linux. The question is how dangerous that will be (it seems even javascript could potentially abuse the security flaw).

On Windows and Mac there will likely be no way to disable the fix and its performance penalty.

[Milos]

On Windows and Mac there will likely be no way to disable the fix and its performance penalty.

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.

[PaulieD]

https://www.extremetech.com/computin...ce-performance

Recent Intel CPUs may not be affected by this issue to the same extent as older chips, but I haven’t been able to confirm that personally.

There are references to using the “nopcid” instruction to disable other features Intel built into its Core microarchitecture to mitigate
the performance hit from separating the kernel and user memory space,
but no clear demarcation on when those mitigating features were themselves introduced.

The nopcid instruction was added with AVX2 support when Haswell was new, which would seem to imply that Intel CPUs pre-Haswell might face larger penalties than chips post-Hawell.

[syzygy]

https://www.fool.com/investing/2017/12/ ... stock.aspx

[MikeGL]

https://www.theregister.co.uk/2018/01/0 ... sign_flaw/

https://www.postgresql.org/message-id/2 ... narazel.de

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

[ZirconiumX]

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.

[syzygy]

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 seems applications with lots of I/O incur the largest performance overhead, whereas purely computational tasks seem to be affected much less:
https://www.phoronix.com/scan.php?page= ... 6pti&num=2

But I would not be surprised if large hashtables increase the penalty. TB access will also be negatively affected, in particular when data is paged in from SSD.

[syzygy]

https://www.theregister.co.uk/2018/01/0 ... sign_flaw/

https://www.postgresql.org/message-id/2 ... narazel.de

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

It is not the same, but 28% is the more accurate number here, at least for certain workloads.

https://lkml.org/lkml/2017/10/31/884

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.

[MikeGL]

https://www.theregister.co.uk/2018/01/0 ... sign_flaw/

https://www.postgresql.org/message-id/2 ... narazel.de

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

It is not the same, but 28% is the more accurate number here, at least for certain workloads.

https://lkml.org/lkml/2017/10/31/884

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.

+1
This cleared my confusion.
Thanks for the link.