[Bug 1560634] Re: [Ubuntu 16.04.1] Provide a way to dynamically enable lock elision on glibc

[Adam Conrad]

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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1560634

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

Status in glibc package in Ubuntu:
  Triaged

Bug description:
  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/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1560634/+subscriptions