On Tue, 21 Oct 2014, Aurelien Jarno wrote:
> On Thu, Oct 16, 2014 at 07:49:29PM -0400, Carlos O'Donell wrote:
> > I disagree. IMO the most flexible approach is for glibc to stop using cpuid
> > for RTM detection and rely on the kernel to tell it if RTM is usable. Then
> > we have a single hardware
On Tue, 21 Oct 2014, Aurelien Jarno wrote:
> I feel sad that the lock elision code can't really be disabled without
> using additional patches that are not even upstream. I have tested your
> blacklist patch, and it works fine on the few systems I have tested.
> I'll therefore go that way.
Thank
On Mon, Oct 20, 2014 at 11:51:14AM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 16 Oct 2014, Carlos O'Donell wrote:
> > I disagree. IMO the most flexible approach is for glibc to stop using cpuid
> > for RTM detection and rely on the kernel to tell it if RTM is usable. Then
> > we have a sin
On Thu, Oct 16, 2014 at 07:49:29PM -0400, Carlos O'Donell wrote:
> I disagree. IMO the most flexible approach is for glibc to stop using cpuid
> for RTM detection and rely on the kernel to tell it if RTM is usable. Then
> we have a single hardware blacklist in the kernel. We need to talk to
> kerne
On Thu, 16 Oct 2014, Carlos O'Donell wrote:
> I disagree. IMO the most flexible approach is for glibc to stop using cpuid
> for RTM detection and rely on the kernel to tell it if RTM is usable. Then
> we have a single hardware blacklist in the kernel. We need to talk to
> kernel people about this.
I disagree. IMO the most flexible approach is for glibc to stop using cpuid
for RTM detection and rely on the kernel to tell it if RTM is usable. Then
we have a single hardware blacklist in the kernel. We need to talk to
kernel people about this. Not to mention we might extend a getauxval-type
API
On Sat, Sep 20, 2014 at 12:05:54AM -0400, Carlos O'Donell wrote:
> On Fri, Sep 19, 2014 at 9:59 PM, Henrique de Moraes Holschuh
> wrote:
> > On Fri, 19 Sep 2014, Carlos O'Donell wrote:
> >> On Fri, Sep 19, 2014 at 6:18 PM, Henrique de Moraes Holschuh
> >> wrote:
> >> > On Fri, 19 Sep 2014, Henriq
On Mon, 29 Sep 2014, Henrique de Moraes Holschuh wrote:
> On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
> Apparently there's at least one codepath that attempts to use lock elision
> regardless of --enable-lock-elision in x86 in rwlock. I'm searching for it.
Indeed it looks like glibc 2
On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
> On Fri, 19 Sep 2014, Carlos O'Donell wrote:
> > On Fri, Sep 19, 2014 at 6:18 PM, Henrique de Moraes Holschuh
> > wrote:
> > > On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
> > >> I can live with that, and I think I can prepare a p
On Sat, 20 Sep 2014, Carlos O'Donell wrote:
> On Fri, Sep 19, 2014 at 9:59 PM, Henrique de Moraes Holschuh
> wrote:
> > On Fri, 19 Sep 2014, Carlos O'Donell wrote:
> >> On Fri, Sep 19, 2014 at 6:18 PM, Henrique de Moraes Holschuh
> >> wrote:
> >> > On Fri, 19 Sep 2014, Henrique de Moraes Holschuh
On Fri, Sep 19, 2014 at 9:59 PM, Henrique de Moraes Holschuh
wrote:
> On Fri, 19 Sep 2014, Carlos O'Donell wrote:
>> On Fri, Sep 19, 2014 at 6:18 PM, Henrique de Moraes Holschuh
>> wrote:
>> > On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
>> >> I can live with that, and I think I can pr
On Fri, 19 Sep 2014, Carlos O'Donell wrote:
> On Fri, Sep 19, 2014 at 6:18 PM, Henrique de Moraes Holschuh
> wrote:
> > On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
> >> I can live with that, and I think I can prepare a patch if you want me to.
> >
> > Here's a minimal patch to glibc th
On Fri, Sep 19, 2014 at 6:18 PM, Henrique de Moraes Holschuh
wrote:
> On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
>> I can live with that, and I think I can prepare a patch if you want me to.
>
> Here's a minimal patch to glibc that should do it (compile tested).
The GNU C Library onl
On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
> I can live with that, and I think I can prepare a patch if you want me to.
Here's a minimal patch to glibc that should do it (compile tested).
This minimal patch does not give the local admin any way to override the
Intel TSX blacklist. I
On Fri, 19 Sep 2014, Aurelien Jarno wrote:
> It looks like Intel did crap there, and that the GNU libc has to handle
> this crap. The microcode update could have stop advertising the
> instructions while still supporting them...
They had their reasons to not do it that way, I suppose. I don't thi
On Fri, Sep 19, 2014 at 10:09:24AM -0300, Henrique de Moraes Holschuh wrote:
> Package: libc6
> Version: 2.19-0experimental0
> Severity: grave
> Justification: causes non-serious data loss
>
> libpthread-2.19 has HLE (hardware-assisted lock elision) support.
> Unfortunately, on Intel-based x86 pro
Package: libc6
Version: 2.19-0experimental0
Severity: grave
Justification: causes non-serious data loss
libpthread-2.19 has HLE (hardware-assisted lock elision) support.
Unfortunately, on Intel-based x86 processors, the use of HLE is currently
hazardous.
Summary: Use of HLE on all current Intel
17 matches
Mail list logo
