Kernel CPU Vulnerability Mitigations: Measuring Their Real Performance Cost on VPS Workloads

Every current Linux kernel ships with CPU vulnerability mitigations enabled by default: Page Table Isolation, retpolines or their successors, speculative-store-bypass controls for the MDS-family faults, and indirect-branch-prediction barriers. They are not free. On a bare-metal workstation the cost is often invisible; inside a VPS, where you are already sharing physical cores through a hypervisor, mitigation overhead stacks on top of virtualisation overhead. The right response is not to disable them wholesale but to measure which of them actually matter to your workload.

Inventory the Current State

# Full mitigation matrix for every vulnerability the kernel knows about
lscpu | grep -i -A2 'Vulnerability'
cat /sys/devices/system/cpu/vulnerabilities/*

# What mitigations are actually compiled and active
cat /proc/cmdline
dmesg | grep -i -E 'spectre|meltdown|mds|retpoline|taa|srbds'

Each file under /sys/devices/system/cpu/vulnerabilities/ reports either Not affected, Vulnerable, or Mitigation: .... Record this matrix before changing anything – it is your baseline, and it can change with kernel updates and microcode revisions.

Which Mitigations Cost What

The costs are not uniform, and knowing which knob maps to which overhead prevents blind disabling.

• Page Table Isolation (PTI) – the answer to Meltdown. Forces a flush of translation structures on every kernel entry and exit, so it hurts syscall-heavy workloads hardest: small-packet networking, high-frequency epoll loops, container syscall traffic. A TLS terminator doing 100k syscalls per second feels it directly. pti=on forces it, pti=off disables it on hosts where it is safe.
• Retpolines and IBRS – address Spectre v2. The cost lands on indirect branch heavy code: interpreters, virtual machines, and the kernel’s own function-pointer dispatch. Compiled-in retpolines are largely mitigated by hardware controls on newer parts; recompiling for -mindirect-branch=thunk is usually a better trade than disabling.
• MDS / TAA / SRBDS – speculative store bypass and related faults. The kernel flushes speculative buffers at context-switch boundaries, which taxes context-switch heavy workloads such as high-connection-count proxies and event loops with many wakeups.
• L1TF / L1D flush – mostly a hypervisor concern that shows up as KVM exit overhead; inside the guest you may not see it at all.

The Runtime Controls

Kernel boot parameters control each family. On the VPS, the guest kernel is yours to configure – these go in /etc/default/grub and require a reboot:

# Baseline: everything on (default)
GRUB_CMDLINE_LINUX_DEFAULT="quiet"

# Selective: turn off only the ones that provably do not pay on this host
# mitigations=auto,nosmt   # auto but disable SMT (rarely wanted)
# mitigations=off          # disable all - see the warning below
# spectre_v2=retpoline     # force the software sequence
# spec_store_bypass_disable=prctl  # per-process opt-in
# pti=on                   # force page table isolation

update-grub && reboot

There is also a per-process opt-in: spec_store_bypass_disable=prctl disables the store-bypass mitigation by default and lets processes re-enable it with the PR_SPEC_ENABLE prctl, so a hardened service can ask for protection while a throughput service opts out.

Measuring the Cost, Not Guessing It

Benchmark the three workload shapes separately, because a mitigation that costs 1% on one can cost 15% on another.

# 1. Syscall-heavy: null syscall throughput
perf bench syscall basic

# 2. Context-switch heavy: scheduler and pipe ping-pong
perf bench sched messaging -l 10000 -g 10
perf bench sched pipe

# 3. Memory/copy and branch heavy
perf bench mem memcpy -l 10000
perf bench futex hash

# Real-app proxies: HTTP throughput against a local nginx
wrk -t4 -c200 -d30s http://127.0.0.1:8080/

Run the full set with mitigations on, reboot with a targeted change, and run again. Differences below 3% are noise on a VPS unless you also hold steal time constant – record vmstat during each run and discard any run where steal moved materially. For most web and application workloads the combined mitigation cost lands in the single digits; for high-syscall proxy and container-dense workloads it can approach 15-20%.

The Security Trade-Off You Are Actually Making

Disabling mitigations on a VPS exposes you to cross-tenant speculative attacks in a way it does not on a dedicated server. On shared hardware, another guest’s malicious code is the exact threat model these mitigations were built for. The defensible positions are narrow:

• Keep everything on for multi-tenant or untrusted-code hosts. The measured cost is usually modest and the threat is real.
• Disable selectively only where you have measured a material cost and the workload is single-tenant with no untrusted code execution – for example a dedicated database instance running only your binaries.
• Never disable globally as a first response to a performance problem. Steal time, disk saturation, and misconfigured pools explain far more slowdowns than mitigations do.

Compensating Instead of Disabling

When page-table isolation is the cost and you need the syscall throughput, the answer is usually architectural rather than a boot flag: batch syscalls with io_uring instead of per-operation read/write, keep more work in userspace with sendfile and splice to avoid copies and transitions, raise net.core.netdev_budget so fewer softirq cycles process more packets, and reduce context switches with connection pooling and larger batches. Each of these removes kernel entries rather than removing the protection that makes kernel entries expensive.

Correct sizing also matters: on an instance with abundant vCPUs, a 5% per-core mitigation cost is absorbed by spare capacity, whereas on a two-core box it is the difference between meeting and missing an SLO. Our managed versus unmanaged hosting comparison covers where hardened, patched kernels and their performance profiles are handled for you, and the virtual versus dedicated server guide explains when moving to single-tenant hardware makes disabling mitigations a defensible option. Audit your own mitigation matrix, benchmark the three workload shapes, and treat every mitigations=off as a measured decision rather than a reflex.

How to Estimate Your Egress Before You Buy

You can produce a usable egress forecast without any monitoring tools, using three inputs: average page weight, monthly page views, and how much of your content a CDN serves from cache. If your average page weighs 1.5 MB and you serve 200,000 page views a month, that is 300 GB of potential egress. If a CDN absorbs 80% of it, your origin sends roughly 60 GB. Compare that against the plan’s included transfer and you immediately know whether you are near a cliff.

• Page weight: check with your browser’s network panel or PageSpeed Insights — it reports total bytes per page load.
• Page views: available from analytics; use last month’s real number, not a projection.
• Cache hit ratio: if you already run a CDN, this is in its dashboard. If not, assume 0% and price the worst case.
• Headroom: target staying under 60% of your included allowance so a viral day does not trigger an overage.

The Cliff Effect in Overage Pricing

Bandwidth allowances on budget plans are not smooth curves; they are cliffs. Below the limit you pay the flat monthly price, and above it you pay a per-GB rate that can transform a cheap plan into an expensive one within a single busy week. This cliff is why the marginal cost of your millionth gigabyte is dramatically higher than the marginal cost of your first. When you model two plans, do not compare their base prices — compare their total cost at your projected volume and at 150% of it. A plan with a higher base price and a generous allowance frequently beats a cheaper plan with a tight cap once realistic traffic is applied.

When Moving Providers Beats Optimising

Compression, caching, and image sizing reduce egress, but there is a floor: you cannot compress below the real content your users request. When you approach that floor and are still fighting overage charges every month, the problem is the provider’s pricing model, not your optimisation. At that point, switching to a host with a more generous transfer allowance or a flat unmetered model is the cheaper engineering decision, even if the sticker price is higher. The signal to switch is simple: if your egress optimisation work is consuming ongoing effort to save a few dollars that a plan change would save outright, you have already paid for the switch in time.