Re: TSX lock elision for glibc v6

["Carlos O'Donell" <carlos at redhat dot com>]

On 05/10/2013 06:41 PM, Andi Kleen wrote:
> History:
> v1: Initial post
> v2: Remove IFUNC use.
> v3: Nested trylock aborts by default now.
>     Trylock enables elision on non-upgraded lock.
>     Various bug fixes.
>     New initializers, remove explicit new lock types in external interface.
>     Add example of abort hook to manual.
>     Fix bugs and clean up the configuration parser.
>     Fix bug in lock busy handling.
>     Fix tst-elision2 which was disabled by mistake earlier.
> v4: (= rtm-devel6)
>     Add missing tst-elision3 file, but not it's tst-elision2
>     Remove abort hook and related code.
>     Use symbolic abort codes
> v5: (= rtm-devel7)
>     Rebased to current master.
>     Use GLIBC_* prefixes for environment variables.
>     Merge environment scan with dynamic linker
>     Fix CPUID id that broke earlier.
>     Minor cleanups.
> v6: Add review feedback on glibc-var.c
> 
> Lock elision using TSX is a technique to optimize lock scaling.
> It allows to run existing locks in parallel using hardware memory
> transactions. New instructions (RTM) are used to control
> memory transactions.
> 
> The full series is available at 
> http://github.com/andikleen/glibc
> git://github.com/andikleen/glibc rtm-devel7
> 
> An overview of lock elision is available at
> http://halobates.de/adding-lock-elision-to-linux.pdf
> 
> LWN article on the topic:
> https://lwn.net/Articles/534758/ 
> 
> See http://software.intel.com/file/41604 for the full
> TSX specification. Running TSX requires either new hardware with TSX
> support, or using the SDE emulator 
> http://software.intel.com/en-us/articles/intel-software-development-emulator/
> 
> This patchkit implements a simple adaptive lock elision algorithm based
> on RTM. It enables elision for the pthread mutexes and rwlocks.
> The algorithm keeps track whether a mutex successfully elides or not,
> and stops eliding for some time when it is not.
> 
> When the CPU supports RTM the elision path is automatically tried,
> otherwise any elision is disabled.
> 
> The adaptation algorithm and its tuning is currently preliminary.
> 
> I cannot post performance numbers at this point.
> 
> The user can also tune this by setting the mutex type and environment
> variables.
> 
> The mutexes can be configured at runtime with the GLIBC_MUTEX
> environment variable.  This will force a specific lock type for all
> mutexes in the program that do not have another type set explicitly.
> This can be done without modifying the program.
> 
> Currently elision is enabled by default on systems that support RTM,
> unless explicitely disabled either in the program or by the user.
> Given more experience we can decide if that is a good idea, or if it
> should be opt-in.

I do not want to ship 2.18 with elision enabled by default.

I want 2.18 to have the option to turn it on, but I do not
have enough confidence to ship with elision enabled by default.

We should start with it disabled and clearly document in the
NEWS for 2.18 how users can enable it.

I'll then turn it on in Fedora Rawhide and we'll start testing
on real hardware over the next 6 months with real users.

Then in 2.19 when we have added some perf benchmarks for
pthreads we can turn it on by default.

Could you please adjust your patch to disable it by default
and post the NEWS entry you want for this new feature along
with a description of how it gets enabled.

The NEWS entry will be part of the public announcement for
the 2.18 release so it does get visibility.

Cheers,
Carlos.