Notes from the Intelpocalypse
Notes from the Intelpocalypse
Posted Jan 4, 2018 9:09 UTC (Thu) by olivlwn (guest, #100387)Parent article: Notes from the Intelpocalypse
Regarding pti, based on articles on Phoronix it seems that the performance cost is not so bad. TBC.
Posted Jan 4, 2018 11:50 UTC (Thu)
by nix (subscriber, #2304)
[Link] (5 responses)
Sorry, if you do anything with the fs the performance cost is clearly appalling, since FSMark isn't *that* synthetic: things like big find(1)s are fairly similar to FSMark in that all they really do is ask the kernel for things lots and lots of times. (Of course, they are also disk-bound operations, so maybe the performance cost is only visible once you have a hot cache, or if you use an SSD.)
Posted Jan 4, 2018 12:15 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (1 responses)
Posted Jan 4, 2018 16:32 UTC (Thu)
by ortalo (guest, #4654)
[Link]
Posted Jan 4, 2018 13:45 UTC (Thu)
by MarcB (subscriber, #101804)
[Link]
This can be filesystem, but also socket operation, or - as it turns out - mprotect.
On one system I am observing about 10 millionen calls to mprotect per minute (not sure, if this is sane). The workload should theoretically be low on syscalls, but it is not. mprotext is followed by futex, nanosleep and then the expected read at around 160k/minute.
Perhaps, a good thing that will come of this is a review of some applications use of syscalls.
The following can give you an idea. It will sample for 60 seconds:
Posted Jan 4, 2018 17:20 UTC (Thu)
by mtanski (guest, #56423)
[Link]
My estimate is about 10% to 15% in real world OLTP database workloads. Databases end up doing a mixture of network / disk IO. Most OLTP queries are getting / returning a handful of tuples so execute time is not dominated by CPU by disk IO. There's usually also a random read pattern (btrees, index indirection). The faster the disk device (100k+ IOPS device) the more impact this will have.
To make this into a one-two punch the KPTI mitigation requires flushing of the TLB. Databases often end doing quite a bit of caching in userspace again with non-ideal locality (random placement) so this will further impact it.
Notes from the Intelpocalypse
Notes from the Intelpocalypse
Notes from the Intelpocalypse
But joke aside, this performance penalty has to be balanced against the actual security needs - and you may try alternative implementations (e.g. with another CPU, another software configuration, etc.).
Notes from the Intelpocalypse
perf stat -e 'syscalls:sys_enter_*' -a sleep 60 2>&1 >/dev/null | sort -n
Notes from the Intelpocalypse