This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: TSX lock elision for glibc v2

From: Andi Kleen <andi at firstfloor dot org>
To: OndÅej BÃlka <neleai at seznam dot cz>
Cc: Andi Kleen <andi at firstfloor dot org>, Torvald Riegel <triegel at redhat dot com>,libc-alpha at sourceware dot org
Date: Sat, 26 Jan 2013 04:50:56 +0100
Subject: Re: TSX lock elision for glibc v2
References: <20130111174120.GK30577@one.firstfloor.org> <1357939708.3375.25889.camel@triegel.csb> <20130111222900.GM30577@one.firstfloor.org> <1358360179.3375.30105.camel@triegel.csb> <m2vcaxyo8k.fsf@firstfloor.org> <1358506817.25369.910.camel@triegel.csb> <20130118233855.GM30577@one.firstfloor.org> <1358873111.3101.870.camel@triegel.csb> <20130122174928.GU30577@one.firstfloor.org> <20130123011141.GA14455@domone>

> In malloc as I described in previous thread locking seem bottleneck.
> Unless with lock elision it would take 10 cycles or so then implementations that 
> avoid locks/atomic are better.

Lock elision is mainly useful for contended locks. It's unlikely to help
with an uncontended lock.

-Andi

References:
- Re: TSX lock elision for glibc v2
  - From: Andi Kleen
- Re: TSX lock elision for glibc v2
  - From: Torvald Riegel
- Re: TSX lock elision for glibc v2
  - From: Andi Kleen
- Re: TSX lock elision for glibc v2
  - From: Torvald Riegel
- Re: TSX lock elision for glibc v2
  - From: Andi Kleen
- Re: TSX lock elision for glibc v2
  - From: Torvald Riegel
- Re: TSX lock elision for glibc v2
  - From: Andi Kleen
- Re: TSX lock elision for glibc v2
  - From: Torvald Riegel
- Re: TSX lock elision for glibc v2
  - From: Andi Kleen
- Re: TSX lock elision for glibc v2
  - From: OndÅej BÃlka

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]