S390: glibc should not be configured with lock elision.

[bugproxy]

== Comment: #0 - Stefan Liebler <email address hidden> - 2016-03-30 03:11:44 ==
Hi,

The current glibc for s390 is configured with --enable-lock-elision.
This could lead to an overall performance regression compared to locks without transactions.
Please disable lock-elsion for s390.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-04-05 04:54 EDT-------
Will this request be made availalbe for 16.04 GA?

[Adam Conrad (adconrad)]

What's wrong with the s390x lock elision implementation that makes it fundamentally worse than other architectures? This is a pretty strange request, given the obvious benefits of lock elision.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-04-06 09:05 EDT-------
(In reply to comment #6)
> What's wrong with the s390x lock elision implementation that makes it
> fundamentally worse than other architectures? This is a pretty strange
> request, given the obvious benefits of lock elision.
We haven't seen real overall advantage, yet.
Thus the current suggestion is to disable it.
Have you compared an usual workload with and without lock elision on s390.
And/Or on other architectures?

[Dimitri John Ledkov (xnox)]

lock elision is enabled by default on s390x, ppc64el, amd64 on Ubuntu.

Note that s390x port of Ubuntu _only_ targets zEC12 and up, thus we can rely on TX (Hardware Transactional Execution / Transacational Memory) to be available.

This is inline with other distributions too, e.g. fedora and opensuse both build with lock elision enabled by default.

http://s390.koji.fedoraproject.org/kojifiles/packages/glibc/2.23.90/2.fc25/data/logs/s390x/build.log

https://build.opensuse.org/package/live_build_log/openSUSE:Factory:zSystems/glibc/standard/s390x

glibc upload has been validated through a full archive rebuild (see announcement on https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001178.html ) and autopkgtest suites for integration testing.

Disabling lock elision at this point of release cycle could only be realistic driven by publicly known hardware issues of shipped zEC12 or later z Systems. Are there any publicly disclosed hardware issues with TX that release team needs to be aware of?

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-04-11 04:25 EDT-------
(In reply to comment #9)
> lock elision is enabled by default on s390x, ppc64el, amd64 on Ubuntu.

Are there any performance measurements available you could share with us regarding this? According to our measurements lock elision was not able to prove being faster in any benchmark or application we tried. We have seen some regressions with it though. I really think such a decision should only be made based on measurements. Everything positive about lock elision I've seen so far were theoretical things which failed hitting real world examples. If it really would be an overall win we would just have made it the default in Glibc.

> This is inline with other distributions too, e.g. fedora and opensuse both
> build with lock elision enabled by default.
>
> http://s390.koji.fedoraproject.org/kojifiles/packages/glibc/2.23.90/2.fc25/
> data/logs/s390x/build.log

Be aware that on Fedora lock elision is currently *only* enabled for S/390 and we already requested removing it. To our knowledge lock elision also on x86 was not able to show any benefits yet. While the Fedora guys turned it off for x86 due to the hardware bug they also mentioned that it will stay disabled until a x86 will show any benefits with it. I would prefer the very same for S/390 as well.

> https://build.opensuse.org/package/live_build_log/openSUSE:Factory:zSystems/
> glibc/standard/s390x

OpenSUSE probably just followed the Fedora example as well.

> Disabling lock elision at this point of release cycle could only be
> realistic driven by publicly known hardware issues of shipped zEC12 or later
> z Systems. Are there any publicly disclosed hardware issues with TX that
> release team needs to be aware of?

No, there are no known hardware issues with the TX implementation.

The only concern we have is that we know there are certain performance regressions without real wins. This might make the Ubuntu release look bad performance-wise in some situations when comparing against the other z enterprise distros.

[Frank Heimes (fheimes)]

Set to 'Won't Fix' in agreement with HWS - better status to handle such cases (Incomplete does not fit very well ...)