Re: [PATCH 0/5] i386: Optimize for Jump Conditional Code Erratum

[Jeff Law <law at redhat dot com>]

On 12/3/19 1:19 PM, H.J. Lu wrote:
> 
>> 4. Shall we default to -mbranches-within-32B-boundaries if the specified
>>    -march= or -mtune= may be affected by the erratum?
> 
> No. It’s a performance mitigation for the microcode update not a
> functional fix. While it can mitigate the potential performance effect
> in most cases as we observed, it increases the code size and may harm
> the performance in some cases. It may also impact the performance of
> those architectures which are not affected by this JCC erratum.
> 
> Software mitigation cannot be applied in some scenarios where
> application behavior is dependent on exact code size. In other words,
> the inserted padding (prefix, nop) may break the assumption of code
> size that the programmer has made.  We have observed such assumptions
> in the compilation of the Linux kernel.
ISTM those cases (like the kernel startup code) could/should opt-opt,
possibly at the file level since IIRC it's just one assembly file where
the sizes of jumps are supposed to be fixed.

> 
> Therefore we do not enable it by default. The user should evaluate its
> impact and make their own determination as to whether to enable the
> software mitigation  knowing that when this option is enabled, the
> performance impact may vary case-by-case.
The problem with not enabling it by default is a distro would have to
inject the flag into their builds.  It's not uncommon for injection
mechanisms to not work on packages like gcc, glibc, etc.

Jeff