[Bug 2007599] Comment bridged from LTC Bugzilla

[bugproxy]

------- Comment From STLI at de.ibm.com 2023-08-09 05:33 EDT-------
Hi Frank,

Sorry, I have not recognized that I should also check 2.35-0ubuntu3.3 package after my verification of 2.35-0ubuntu3.2 (see some comments above).
Nevertheless, I've installed the update and checked again:

$ /lib/ld64.so.1 --version
ld.so (Ubuntu GLIBC 2.35-0ubuntu3.3) stable release version 2.35.
...

$ /lib/ld64.so.1 --list-tunables | grep hwcaps
glibc.cpu.hwcaps:
=> Now this GLIBC_TUNABLES is also available on s390x.
When setting the tunables, you also see the value:
$ GLIBC_TUNABLES="glibc.cpu.hwcaps=z13" /lib/ld64.so.1 --list-tunables | grep hwcaps
glibc.cpu.hwcaps: z13

Furthermore I've run a small test program which calls the IFUNC'ed functions memmove, memmem, strstr and UTF8_UTF16_Z9.so via iconv-conversion from UTF16BE to UTF8.
Running gdb with setting the GLIBC_TUNABLES in different flavors like this ...
gdb$ set environment GLIBC_TUNABLES glibc.cpu.hwcaps=z13
... leads to breaking in the different ifunc-variants of the mentioned functions.

Thanks again for integration.

-- 
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/2007599

Title:
  [23.04 FEAT] [GNU2223] glibc - Influence hwcaps/stfle via
  GLIBC_TUNABLES glibc.cpu.hwcaps

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in glibc package in Ubuntu:
  Fix Released
Status in glibc source package in Jammy:
  Fix Committed
Status in glibc source package in Kinetic:
  Won't Fix
Status in glibc source package in Lunar:
  Fix Released

Bug description:
  SRU Justification:
  ==================
  [Business Case]
  The Eclipse OpenJ9 project is developing an "InstantOn" technology that leverages Linux's Checkpoint/Restore In Userspace (CRIU) feature. By restoring the JVM process from an existing CRIU snapshot, application can start-up up to 18x faster, without any compromises to throughput or JVM capabilities. This technology is ideal for serverless computing and scaling micro services in containerized deployments.
  IBM WebSphere Liberty is one of the first exploiters of OpenJ9 InstantOn technology and have measured 10x faster start-up. In a 2021 survey with Java customers on IBM Z, 80% of users ranked initial start-up / ramp-up performance as an important metric. Other Java-based middleware and libraries can also take advantage of this technology for the significant start-up improvements. This GLIBC patch addresses a functional portability issue that is encountered when users create a container image with a CRIU snapshot on a newer hardware level and deploy this image against older hardware. GLIBC caches hardware facilities, which may not be available on the older deployment target, resulting in potential illegal instructions. With GLIBC_TUNABLES fixed to influence hwcaps and stfle bits on s390x, it allows the snapshot environment to mimic older hardware levels for the snapshot.

  [Impact]
  * For IFUNC'ed functions within glibc, the decision can now be influenced with GLIBC_TUNABLE: glibc.cpu.hwcaps
  * This can be used as test vehicle
  * This is a prerequisite for Eclipse OpenJ9 projects "InstantOn" technology which speeds up start-up times by factors.

  [Test Plan]
  * Prepare an IBM z15 LPAR with Ubuntu (incl. this patch)
  * Check if patch is applied by running command "/usr/lib/s390x-linux-gnu/ld64.so.1 --list-tunables" and check if the new tunable "glibc.cpu.hwcaps" is listed
  * Prepare a small test-program calling IFUNC-optimized functions: memmem, strstr and memmove.
  * Start a gdb session and break at __memmem_vx, __memmem_arch13, __strstr_vx, __strstr_arch13, __memmove_z13 and __memmove_arch13. Run the program and you should always stop in the arch13=z15 functions. Now use gdb-command "set environment GLIBC_TUNABLES glibc.cpu.hwcaps=z13" and run again. Now you should always stop in the vx=z13 functions.

  [Original report]
  Feature Description:

  In glibc there are a lot of IFUNC-optimized functions, where we have
  different implementations for e.g. z13, z14, z15, ... . At runtime the
  best implementation is chosen depending on the available HWCAP-/STFLE-
  bits.

  We need to have a mechanism to influence this decision. There already exists such a mechanism for x86 which is documented here:
  GLIBC_TUNABLE: glibc.cpu.hwcaps (x86 variant)

  https://www.gnu.org/software/libc/manual/html_node/Hardware-
  Capability-Tunables.html

  Therefore we've developed the commit
  "S390: Influence hwcaps/stfle via GLIBC_TUNABLES." (https://sourceware.org/git/?p=glibc.git;a=commit;h=41f67ccbe92b4fd09e1062b383e55e407ae5bfa1)
  as part of our maintenance work. The s390-variant of the mentioned tunable is able to add/remove specific HWCAP-/STFLE-bits used by the IFUNC-resolvers inside glibc. Furthermore we can set the architecture-level like z13 to influence multiple bits at once.

  One can query if the feature is available with (useful to check if this feature is also backported to current distro or not):
  $ /lib/ld64.so.1 --list-tunables

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2007599/+subscriptions