All the major Linux distributions have now released their Intel chip meltdown patches. But, someone must retune all those servers to get their performance up to speed and replace network devices and servers running up-to-date Linux distros.
The Intel Meltdown security problem is the pain that just keeps hurting. Still, there is some good news. Ubuntu and Debian Linux have patched their distributions. The bad news? It’s becoming clearer than ever that fixing Meltdown causes significant performance problems. Worst still, many older servers and appliances are running insecure, unpatchable Linux distributions.
But first, let’s look at what happens to performance with the patches. Red Hat’s Meltdown/Spectre performance benchmarks found with the Linux Meltdown patches have the following performance problems:
- Measurable: 8 percent to 19 percent — Highly cached random memory with buffered I/O, OLTP database workloads, and benchmarks with high kernel-to-user space transitions are impacted between 8 percent to 19 percent. Examples include OLTP Workloads (tpc), sysbench, pgbench, netperf (< 256 byte), and fio (random I/O to NvME).
- Modest: 3 percent to 7 percent — Database analytics, Decision Support System (DSS), and Java VMs are impacted less than the “Measurable” category. These applications may have significant sequential disk or network traffic, but kernel/device drivers are able to aggregate requests to moderate level of kernel-to-user transitions. Examples include SPECjbb2005, Queries/Hour, and overall analytic timing (sec).
- Small: 2 percent to 5 percent — HPC (High Performance Computing) CPU-intensive workloads are affected the least, with only 2 percent to 5 percent performance impact, because jobs run mostly in user space and are scheduled using cpu-pinning or numa-control. Examples include Linpack NxN on x86 and SPECcpu2006.
- Minimal: Linux accelerator technologies that generally bypass the kernel in favor of user direct access are the least affected, with less than 2 percent overhead measured. Examples tested include DPDK (VsPERF at 64 byte) and OpenOnload (STAC-N). Userspace accesses to VDSO like get-time-of-day are not impacted. We expect similar minimal impact for other offloads.
But, as Richard Morrell, CTO and security lead of Falanx Group Ltd (LON:FLX), a cyber defense company, points out: “Many (a lot) of these devices are still running platforms that started out in the development lab at the vendor as CentOS 4/5/6/7 development trees. For the later versions that’s fine and dandy, kernel and microcode patches are available due to CentOS benefitting from the hard work Red Hat did to get the patches out for a multitude of architectures.” But, many of the older “devices are running versions 4 and 5 and have long since departed from being ‘standard builds.”
