From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | PSA: New intel MDS vulnerability mitigations cause measurable slowdown |
Date: | 2019-05-14 22:30:52 |
Message-ID: | 20190514223052.2iufhkjmgod2h7ic@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
There's a new set of CPU vulnerabilities, so far only affecting intel
CPUs. Cribbing from the linux-kernel announcement I'm referring to
https://xenbits.xen.org/xsa/advisory-297.html
for details.
The "fix" is for the OS to perform some extra mitigations:
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html
https://www.kernel.org/doc/html/latest/x86/mds.html#mds
*And* SMT/hyperthreading needs to be disabled, to be fully safe.
Fun.
I've run a quick pgbench benchmark:
*Without* disabling SMT, for readonly pgbench, I'm seeing regressions
between 7-11%, depending on the size of shared_buffers (and some runtime
variations). That's just on my laptop, with an i7-6820HQ / Haswell CPU.
I'd be surprised if there weren't adversarial loads with bigger
slowdowns - what gets more expensive with the mitigations is syscalls.
Most OSs / distributions either have rolled these changes out already,
or will do so soon. So it's likely that most of us and our users will be
affected by this soon. At least on linux the part of the mitigation
that makes syscalls slower (blowing away buffers at the end of a sycall)
is enabled by default, but SMT is not disabled by default.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-05-14 22:51:20 | Re: vacuumdb and new VACUUM options |
Previous Message | Andres Freund | 2019-05-14 20:37:14 | Re: Inconsistency between table am callback and table function names |