SUSE Labs Conference 2020 - No Slower than 10%!
Channel: SUSE Labs
Date: 2020-10-05

Conference held using #BigBlueButton

Good performance and low overhead are always something highly desirable. In virtualization, a commonly used metric is comparing with baremetal. This basically means running the same workload on a baremetal system and, afterward, inside a VM and measuring the performance degradation, due to the overhead introduced by the virtualization layer. Now, how big such a performance drop is, depends on a number of factors ranging from hardware capabilities, to availability of specific features on either the host or the guest, or even on the configuration of host and guest.

So, what do you do if you have a requirement stating that a certain app, workload, or benchmark, when running inside a VM must never incur a slowdown higher than X% (e.g., never higher than 10%)? Well, you run the workload or benchmark of interest a lot of times (and I mean it, a lot of times!) and, for each of these runs, you enable or disable a specific feature or try a special configuration, chasing any --however small-- favorable change in the results, until you meet your KPI(s?).

We have recently done exactly this, by running some SAP HANA benchmarks inside a few VMs, with the goal of keeping the virtualization overhead below certain well-defined thresholds, on top of SLE15 SP2 (both hosts and guests). This has led us to identify a path made of features in need to be enabled in the KVM hypervisor (like the "hint-dedicated") or in the guest kernel (like the "cpuidle-haltpoll" governor). It also resulted in us discovering which one, for instance, was the best network IO configuration (e.g., virtual, pci-passthrough, SRIOV, ...) for the workloads of interest and on the hardware being used. Last but not least, it forced us to deal with the (in)famous mitigations for the speculative execution hardware bugs, for understanding how and by how much each one of them was slowing down our experiments.

During this session, we will give a report on that journey. Of course, we will show how the fully tuned configuration of host and guest --the one that is helping us meeting our KPIs-- looks like. You'll see that it contains all the usual suspects (e.g., vCPU pinning, huge-pages, etc.), but also something new (e.g., haltpoll, all the mitigations considerations, etc). But we will also explain how we got there, the issues we encountered, and the false trails we were tricked into following until they turned out to be dead ends.

In summary, come and listen to how we made our VM no slower than 10% with respect to baremetal (for our benchmarks and on our hardware, of course) and to what we've learned in the process.