On Sun, 18 Oct 2015, Aurelien Jarno wrote:
> On 2015-10-07 07:32, Henrique de Moraes Holschuh wrote:
> > Meanwhile, a suggestion by Samuel Thibault to try to use hwcap did
> > provide for a possible long-term plan to fine-tune the lock-elision
> > blacklist (and anything else of that sort).
> >
>
On Sun, 18 Oct 2015, Aurelien Jarno wrote:
> > Broadwell-H with a very recent microcode update (rev 0x12, from
> > 2015-06-04) was confirmed to have broken TSX-NI (RTM) and to _leave it
> > enabled_ in CPUID, causing glibc with lock elision enabled to SIGSEGV.
> > An even more recent Broadwell-H m
On 2015-10-07 07:32, Henrique de Moraes Holschuh wrote:
> Meanwhile, a suggestion by Samuel Thibault to try to use hwcap did
> provide for a possible long-term plan to fine-tune the lock-elision
> blacklist (and anything else of that sort).
>
> We would have to (finally) extend x86-64 hwcap to cpu
On 2015-10-08 22:20, Henrique de Moraes Holschuh wrote:
> tag 800574 + patch
> thanks
>
> Attached updated version of amd64/local-blacklist-on-TSX-Haswell.diff.
> I believe it should be renamed to
> "amd64/local-blacklist-for-Intel-TSX.diff" as it is not just about Intel
> Haswell anymore.
>
>
tag 800574 + patch
thanks
Attached updated version of amd64/local-blacklist-on-TSX-Haswell.diff.
I believe it should be renamed to
"amd64/local-blacklist-for-Intel-TSX.diff" as it is not just about Intel
Haswell anymore.
The updated patch has been package-compile-tested on glibc 2.19-22.
This
Well, I've finally finished analysing things for Broadwell.
The amd64 (x86-64) glibc lock elision code keys on the RTM CPUID bit
because it is actually using RTM (and not HLE) to implement lock
elision. I failed to keep this in mind when worrying about permanently
blacklisting Broadwell processor
6 matches
Mail list logo
