On Thu Jan 04 17:09:23 2018, bconry wrote:
> In light of the recent news about Meltdown and Specter, and the expected
> performance hit related to the fix for Meltdown, AT&T has asked if we're
> looking into this API.
=> I looked at extended description of Meltdown to understand
how it can affect performances:
- to summary the Meltdown issue is a timing attack against
the way the TLB (Translation Lookahead Buffer, the first step
hardware assisted in virtual to real address mapping) is shared
between the user space (ring 3) and kernel space (ring 0)
during aggressive speculative execution of instructions.
- note it is not clear if the issue extends to isolation between
virtual machines, i.e. with ring inferior to 0. But IMHO because
of the performance advantages the feature source of Meltdown
provides I am afraid virtual machines are impacted too.
Azure and AWS scheduled updates seem to confirm that too.
- there are two ways to fix the problem. The first one is a better
architecture design (i.e. MIPS or IBM vs Intel or ARM) but it should
not be a surprise that performance won over security (e.g.
security people insist about Harvard (separate data and instruction
caches) architecture...).
- second way is to not share the kernel page tables with/between
user processes (Linux, Windows, macOS, ... patches) but this means
the TLB is flushed at each context switch between user and kernel
spaces (roughly system calls).
- so the overhead in Meltdown fix is from context switches.
It is a good news for any network server because performance
is largely dominated by network costs.
- note for benchmarking it becomes critical to put the Testing
Node and the Node Under Test on different physical boxes
(BTW it is the common setup).
- to come back to the ticket subject any way to lower the
number of system calls is good (BTW this idea was behind
adaptive rw locks as on Linux locks are system calls).