2018 is going to be remembered as a year when it really went bad for every processor on board, and for the companies like Intel, AMD and others. And it’s not getting any better. While patches for Meltdown and Spectre are being rolled out for all PCs, a recent report is suggesting that these patches had hit some of the newer CPUs with reboot issues. This includes Ivy Bridge, Sandy Bridge, Skylake, and Kaby Lake CPUs.
Intel says that they have reproduced these issues internally and are making progress toward identifying the root cause. In parallel, Intel will be providing beta microcode to vendors for validation by next week. In spite of this Intel wants all the OEMs to keep rolling out an update to close the flaw, so no data is compromised. Pretty tough time for Intel.
When it comes to performance, Intel shared a lot of details which in short means the impact of the Spectre fix can be as much as 25% for some workloads. If a workload uses a lot of kernel privilege changes and spends a significant amount of time in privileged mode, it will be more adversely impacted.
To summarize what we’ve seen in testing so far:
Impacts ranging from 0-2% on industry-standard measures of integer and floating point throughput, Linpack, STREAM, server-side Java and energy efficiency benchmarks. These benchmarks represent several common workloads important to enterprise and cloud customers.
An online transaction processing (OLTP) benchmark simulating modeling a brokerage firm’s customer-broker-stock exchange interaction showed a 4% impact. More analytics testing is in process and the results will be dependent on system configuration, test setup and benchmark used.
Benchmarks for storage also showed a range of results depending on the benchmark, test setup and system configuration:ForFlexibleIO, a benchmark simulating different types of I/Oloads, results depend on many factors, including read/write mix, block size, drives and CPU utilization. When we conducted testing to stress the CPU (100% write case), we saw an 18% decrease in throughput performance because there was not CPU utilization headroom. When we used a 70/30 read/write model, we saw a 2% decrease in throughput performance. When CPU utilization was low (100% read case), as is the case with common storage provisioning, we saw an increase in CPU utilization, but no throughput performance impact.
Storage Performance Development Kit (SPDK) tests, which provide a set of tools and libraries for writing high performance, scalable, user-mode storage applications, were measured in multiple test configurations. Using SPDK iSCSI, we saw as much as a 25% impact while using only a single core. Using SPDK vHost, we saw no impact.