Bug#875618: openblas: please enable build on s390x

[Sébastien Villemot]

[CC’ing the debian-***@lists.debian.org list; s390 folks, please keep the bug
in CC on replies]

Dear Graham,

Source: openblas
Version: 0.2.20+ds-1
Severity: wishlist
IBM Z: * New target z13 with BLAS3 optimizations
I have just checked, and openblas/0.2.20-3 builds successfully on
zelenka.debian.org.
Please enable building on s390x.

Unfortunately it does not look that simple. OpenBLAS is optimized for z13, but
our s390x port is supposed to support all the z systems (see [1]).

In particular, the OpenBLAS build system adds the "-march=z13 -mzvector"
compilation flags. If I remove them, then the package fails to build on
zelenka: it complains about unknown assembly instructions, which are not
present on old z-systems. This is the proof that OpenBLAS cannot produce a
binary generic enough for our s390x port.

So unless I am missing something, it’s not possible to enable building for
s390x until 1) OpenBLAS supports older z-systems or 2) the hardware
requirements for the Debian s390x port are upgraded.

Best,

[1] https://www.debian.org/releases/stable/s390x/ch02s01.html.en#idm45373715987328

[PICCA Frederic-Emmanuel]

Hello

Post by Sébastien Villemot
Unfortunately it does not look that simple. OpenBLAS is optimized for z13, but
our s390x port is supposed to support all the z systems (see [1]).

what about asking for a a z13-support package to the isa-support (source package) maintainer.
This way it could be possible to upload an optimise vesion of openblas which can install on recent enought s390x machines.

the question will be then : does the buildd support these instructions ?

Cheers

Fred

[Sébastien Villemot]

Post by PICCA Frederic-Emmanuel
Hello

Post by Sébastien Villemot
Unfortunately it does not look that simple. OpenBLAS is optimized for z13, but
our s390x port is supposed to support all the z systems (see [1]).

what about asking for a a z13-support package to the isa-support (source
package) maintainer. This way it could be possible to upload an optimise
vesion of openblas which can install on recent enought s390x machines.

I am not totally convinced by this solution. If we adopt it, somebody who
installs e.g. octave on an old system-z machine will be hit by a failure in the
dpkg installation process, which needs manual intervention. This is likely to
generate problems in automated installers (and also confuse and annoy system
admins).

Post by PICCA Frederic-Emmanuel
the question will be then : does the buildd support these instructions ?

I leave that to the s390 porters to answer.

[Christian Borntraeger]

Post by Sébastien Villemot

Post by PICCA Frederic-Emmanuel
Hello

Post by Sébastien Villemot
Unfortunately it does not look that simple. OpenBLAS is optimized for z13, but
our s390x port is supposed to support all the z systems (see [1]).

what about asking for a a z13-support package to the isa-support (source
package) maintainer. This way it could be possible to upload an optimise
vesion of openblas which can install on recent enought s390x machines.

I am not totally convinced by this solution. If we adopt it, somebody who
installs e.g. octave on an old system-z machine will be hit by a failure in the
dpkg installation process, which needs manual intervention. This is likely to
generate problems in automated installers (and also confuse and annoy system
admins).

Post by PICCA Frederic-Emmanuel
the question will be then : does the buildd support these instructions ?

I leave that to the s390 porters to answer.

FWIW, some years ago I did the atlas port for s390x. For dynamic linking the atlas
build/package process did support the exploitation of ELF HW_CAPS. So you could
build a z900 (generic) and a z13 variant which is then picked by the linker at
runtime. No idea if openblas allows the same. Of course the static variant (.a)
must be the generic one.

Christian

[Sébastien Villemot]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/xianyi/OpenBLAS/issues/1307

Post by Christian Borntraeger

Post by Sébastien Villemot

Post by PICCA Frederic-Emmanuel

Post by Sébastien Villemot
Unfortunately it does not look that simple. OpenBLAS is optimized for z13, but
our s390x port is supposed to support all the z systems (see [1]).

what about asking for a a z13-support package to the isa-support (source
package) maintainer. This way it could be possible to upload an optimise
vesion of openblas which can install on recent enought s390x machines.

I am not totally convinced by this solution. If we adopt it, somebody who
installs e.g. octave on an old system-z machine will be hit by a failure in the
dpkg installation process, which needs manual intervention. This is likely to
generate problems in automated installers (and also confuse and annoy system
admins).

Post by PICCA Frederic-Emmanuel
the question will be then : does the buildd support these instructions ?

I leave that to the s390 porters to answer.

FWIW, some years ago I did the atlas port for s390x. For dynamic linking the atlas
build/package process did support the exploitation of ELF HW_CAPS. So you could
build a z900 (generic) and a z13 variant which is then picked by the linker at
runtime. No idea if openblas allows the same. Of course the static variant (.a)
must be the generic one.

Thanks for your feedback. I have opened a request upstream about the need for a
z900 kernel, and for a dynamic selection between the z900 and z13 kernels
(as OpenBLAS currently does on x86).

[Sébastien Villemot]

Control: tags -1 = pending
Control: notforwarded -1

Post by Sébastien Villemot

Post by Christian Borntraeger

Post by Sébastien Villemot

Post by PICCA Frederic-Emmanuel

Post by Sébastien Villemot
Unfortunately it does not look that simple. OpenBLAS is optimized for z13, but
our s390x port is supposed to support all the z systems (see [1]).

what about asking for a a z13-support package to the isa-support (source
package) maintainer. This way it could be possible to upload an optimise
vesion of openblas which can install on recent enought s390x machines.

I am not totally convinced by this solution. If we adopt it, somebody who
installs e.g. octave on an old system-z machine will be hit by a failure in the
dpkg installation process, which needs manual intervention. This is likely to
generate problems in automated installers (and also confuse and annoy system
admins).

Post by PICCA Frederic-Emmanuel
the question will be then : does the buildd support these instructions ?

I leave that to the s390 porters to answer.

FWIW, some years ago I did the atlas port for s390x. For dynamic linking the atlas
build/package process did support the exploitation of ELF HW_CAPS. So you could
build a z900 (generic) and a z13 variant which is then picked by the linker at
runtime. No idea if openblas allows the same. Of course the static variant (.a)
must be the generic one.

Thanks for your feedback. I have opened a request upstream about the need for a
z900 kernel, and for a dynamic selection between the z900 and z13 kernels
(as OpenBLAS currently does on x86).

It turns out that there is already a support for generic System z, I had
overlooked that.

I have therefore pushed a changeset that builds a generic s390x binary.

However, upstream does not currently provide runtime detection, so owners of a
z13 system will have to recompile locally (as explained in README.Debian) in
order to get the best out of OpenBLAS (note that this is the same situation as
all the non-x86 archs).