References: X-Mailer: MIME-tools 5.508 (Entity 5.508) In-Reply-To: Content-Disposition: inline Message-ID: X-RT-Original-Encoding: utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: binary Content-Type: text/plain; charset="utf-8" X-RT-Interface: Web RT-Send-CC: Content-Length: 1971 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).