Date: Fri, 5 Jan 2018 07:30:48 -0500 From: Eric McCorkle <eric@metricspace.net> To: =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= <des@des.no> Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org> Subject: Re: A more general possible meltdown/spectre countermeasure Message-ID: <4bad69c4-6fc7-6735-6b15-81baaee358f3@metricspace.net> In-Reply-To: <86efn4u3fv.fsf@desk.des.no> References: <c98b7ac3-26f0-81ee-2769-432697f876e5@metricspace.net> <86efn4u3fv.fsf@desk.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/05/2018 03:15, Dag-Erling Smørgrav wrote: > Eric McCorkle <eric@metricspace.net> writes: >> The obvious downside is that you take a performance hit storing things >> in non-cacheable locations, especially if you plan on doing heavy >> computation in that memory (say, encryption/decryption). However, this >> is almost certainly going to be less than the projected 30-50% >> performance hit from other mitigations. > > Where did you get those numbers? Because the worst documented case for > KPTI is ~20% for I/O-intensive workloads, and PCID is likely to bring > this down to single digits if used correctly. The KAISER paper claims a > slowdown of < 1%, but that may have been the result of undisclosed > features of the specific CPU they tested on. Those were numbers being thrown around. I'm not putting a lot of stake in them.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4bad69c4-6fc7-6735-6b15-81baaee358f3>