[Ubuntu 16.04.1] Provide a way to dynamically enable lock elision on glibc

[bugproxy]

We identified that, in some scenarios, lock elision can cause performance regressions.
In order to minimize this, we prepared a patch for POWER that disables lock elision by default even when glibc is built with --enable-lock-elision.
It's enabled only when GLIBC_ELISION_ENABLE=yes is available in the environment and when the hardware supports it.

This patch has already been sent upstream [1], but the community asked us to re-implement it based on the tunables framework. It's now blocked waiting for the acceptance of the tunables framework [2] [3] [4]. The discussion around the tunables framework is already old and the community cannot agree yet on a way to pass the tuning parameters.
We had an agreement it would be integrated into glibc 2.23, which didn't happen and due to other issues, we don't believe this will happen until glibc 2.24.

Meanwhile, in order to solve the regression issues reported by current customers, would you consider to accept the following patch?
It's very close to patch [1], which has already been refused upstream.

[1] http://patchwork.sourceware.org/patch/8529/
[2] http://patchwork.sourceware.org/patch/10405/
[3] http://patchwork.sourceware.org/patch/10405/
[4] http://patchwork.sourceware.org/patch/10342/

[bugproxy (bugproxy)]

Default Comment by Bridge

[Steve Langasek (vorlon)]

Adam, please evaluate for 16.04. Thanks!

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-07-25 09:59 EDT-------
Was it evaluated or is is still to be done for 16.04.1 ?

[bugproxy (bugproxy)]

Default Comment by Bridge

[William J. Schmidt (wschmidt-g)]

It looks like this has never been integrated?

[Adam Conrad (adconrad)]

Curiously, the patchwork comments there point to kernels << 4.2 being the major cause of the performance regressions brought about by TLE. Was it actually 16.04 customers (on 16.04 kernels) that caused this bug to be opened, or was it that you identified the issue on RedHat and then proposed the patch to all the distros?

We're looking at potentially disabling TLE by default for entirely different reasons (though, still mulling that over), but based on my reading of the patchwork discussion, this patch seems like it shouldn't really be necessary to address performance concerns on a system running 4.4 and higher kernels, as 16.04 is.

Certainly, there's the minor concern of people running Ubuntu 16.04 in a chroot or container on top of a much older host kernel, but while that's a configuration that happens to work, it's not one we explicitly support[1] or encourage either.

[1] With the notable exception that we support 16.04 containers on 14.04 but, then again, 14.04 has the 4.4 kernel available as well.

[Adam Conrad (adconrad)]

The above comment aside, we might end up disabling lock elision on *all* the architectures that support it due to fears of broken software in the wild that violates pthread double-unlock rules, something only coming to light recently due to ppc64el/s390x users being very much in a minority, and x86 users only starting to see the issues as they refresh to hardware new enough to support hardware lock elision.

[Chris Feyerchak (cfeyer)]

There's documentation at [1] of crashes in at least three different applications being avoided by disabling lock elision. Rebuilding glibc is restrictive for a lot of the impacted users. I'd be in favor of any of the following solutions:
a) disabling lock elision by default
b) providing a means of disabling lock elision at runtime
c) adding an alternative glibc *.deb to the repositories that can easily be installed with an "apt-get install" or similar.

[1] https://github.com/MyrtleSoftware/glibc-no-lock-elision

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-12-05 06:59 EDT-------
> There's documentation at [1] of crashes in at least three different
> applications being avoided by disabling lock elision.

This patch tries to solve exactly those kind of problems.
Lock elision will continue to be available, but will be disabled by default.

Users could enable it if variable GLIBC_ELISION_ENABLE=yes is available in the environment.