[Bug nptl/17351] No hardware with functional lock elision available

["carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17351

--- Comment #5 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Cedric BAIL from comment #4)
> Checking the CPU RTM bit is not enough for application, they also need to
> check the microcode version (This is the reason why glibc is turning on
> elision when it should not use it in my opinion).

You misunderstand. We will not protect you from faulty hardware. The choice is
up to the user to apply the microcode update or not. It is *after* the
microcode update that the RTM-enabled CPU with errata will have the RTM bit
disabled, and therefore glibc will not use elision. On RTM-enabled CPUs that
don't have the errata the RTM bit will be enabled and glibc will use elision.
The library will not attempt to check the microcode version to disable elision,
that is the responsibility of the user. All I was clarifying was that after the
microcode update the library does the right thing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.