Thanks for running those benchmarks testing our Meltdown mitigation, Michael! The results are about what we expected. The more system-call-heavy an application is, the more it suffers from the ~150 to ~250nS of additional system call / interrupt / exception overhead. The less system-call-heavy, the less it suffers.
Someone asked about PCID. DragonFlyBSD does not currently implement PCID so the results you are seeing are from two %cr3 loads without PCID in the system call path. I don't know what the difference would be... PCID didn't actually do a whole lot when we tested it a year or two ago, because it's only applicable for major process context switches and those are already well-managed by the scheduler. (Well, and virtualization too, but virtualization is not DragonFly's strong point). However, I will be looking at using PCID again to potentially reduce the impact of this mitigation, since Meltdown on Intel requires the MMU to be reloaded twice in these heavily used code paths.
The linux guys are saying that Meltdown losses are roughly cut in half with PCID in these code paths. That makes sense. But its still bad.
IBRS (one of the Intel Microcode mitigations) is even worse. If you enable IBRS at all times (that would be linux ibrs mode 2), performance is completely destroyed for just about everything. We're talking 30% or worse. For everything. IBRS has to be left on all the time to protect against two types of Spectre attacks --- same process (e.g. javascript -> client browser) attacks, and sibling hyper-thread attacks. I consider Intel's microcode fixes to be a non-starter, honestly. They are unusable. I'll put support in DragonFly anyway, soon, but I consider it worthless. Spectre will not be truly fixed without new silicon... probably 6 months to a 12 months away, or worse.
With IBRS, system call overhead increases from 380ns to 780ns on the one machine I have been able to test it on so far (an older Haswell), and performance is lost across far more than just the system call boundary.
The partial IBRS mitigations across the user->kernel boundary provided by Intel are... I'm still vomiting.
-Matt
Someone asked about PCID. DragonFlyBSD does not currently implement PCID so the results you are seeing are from two %cr3 loads without PCID in the system call path. I don't know what the difference would be... PCID didn't actually do a whole lot when we tested it a year or two ago, because it's only applicable for major process context switches and those are already well-managed by the scheduler. (Well, and virtualization too, but virtualization is not DragonFly's strong point). However, I will be looking at using PCID again to potentially reduce the impact of this mitigation, since Meltdown on Intel requires the MMU to be reloaded twice in these heavily used code paths.
The linux guys are saying that Meltdown losses are roughly cut in half with PCID in these code paths. That makes sense. But its still bad.
IBRS (one of the Intel Microcode mitigations) is even worse. If you enable IBRS at all times (that would be linux ibrs mode 2), performance is completely destroyed for just about everything. We're talking 30% or worse. For everything. IBRS has to be left on all the time to protect against two types of Spectre attacks --- same process (e.g. javascript -> client browser) attacks, and sibling hyper-thread attacks. I consider Intel's microcode fixes to be a non-starter, honestly. They are unusable. I'll put support in DragonFly anyway, soon, but I consider it worthless. Spectre will not be truly fixed without new silicon... probably 6 months to a 12 months away, or worse.
With IBRS, system call overhead increases from 380ns to 780ns on the one machine I have been able to test it on so far (an older Haswell), and performance is lost across far more than just the system call boundary.
The partial IBRS mitigations across the user->kernel boundary provided by Intel are... I'm still vomiting.
-Matt
Comment