We have rebased a large part of the glibc dynamic loader and the x86 CPU detection infrastructure to the current upstream version. These changes are going to land in CentOS Stream soon.
These glibc changes mean that going forward, run-time selection of optimized shared object implementations is possible for all x86 processors (e.g., generic AVX2-optimized code that gets loaded on EPYC and Xeon Scalable processors). This is primarily being done to allow user application code to leverage this functionality. At this time, we are not adjusting or optimizing CentOS Stream packages themselves.
Convenient developer support depends on GCC Toolset 11 and LLVM Toolset 12, which are yet to be released (even in their upstream versions). I’m working on some form of documentation on how to produce builds that are compatible with this feature for earlier toolchain versions.
Other changes in the new glibc version include:
* Backwards-compatible ld.so cache format changes to support glibc-hwcaps
* --argv0 support in ld.so
* DT_AUDIT support: The --audit option in binutils ld finally works as expected.
* Enhanced --help output in ld.so: “/lib64/ld-linux-x86-64.so.2 --help” shows library search path information.
* TLS allocation improvements: dlopen is able to load shared objects that use initial-exec TLS in more cases. There is a new glibc.rtld.optional_static_tls tunable to support exceptionally large initial-exec TLS usage after dlopen.
* The CPU tunable namespace has been renamed from “glibc.tune” to “glibc.cpu”.
If you have any questions, please feel free to ask on-list.
Thanks, Florian
On 07/01/2021 19:04, Florian Weimer wrote:
We have rebased a large part of the glibc dynamic loader and the x86 CPU detection infrastructure to the current upstream version. These changes are going to land in CentOS Stream soon.
Hi Florian,
Thanks a lot for the announce, really appreciated to be aware of what's coming . I'd (myself) like to see some kind of announces being sent on the public list so that everybody can follow what's being worked on and so what to expect in Stream packages (as of course there is no official public Release Notes -yet- , appearing for RHEL, so downstream)
Wondering if such initiative wouldn't be good to : as development will be more and more transparent, what about also "up2date" doc about new backported features , etc ?
Now back to the x86 cpu infra : does that mean that to *build* Stream packages (like gblic) we need at least a minimum instructions set in the CPU (builder side that is) ?
Kind Regards,
* Fabian Arrotin:
Thanks a lot for the announce, really appreciated to be aware of what's coming . I'd (myself) like to see some kind of announces being sent on the public list so that everybody can follow what's being worked on and so what to expect in Stream packages (as of course there is no official public Release Notes -yet- , appearing for RHEL, so downstream)
I'm going to let others comment on that.
Now back to the x86 cpu infra : does that mean that to *build* Stream packages (like gblic) we need at least a minimum instructions set in the CPU (builder side that is) ?
glibc itself continues to use IFUNCs on x86-64 to select optimized function implementations, based on CPU capabilities. This means that baseline x86-64 support remains sufficient for building the glibc package.
I can image that in the future, there will be some packages which build shared objects for x86-64-v3 (in addition to baseline x86-64, with run-time selection later), and which test all implementations at build time. In such a scenario, the builders would have to support x86-64-v3.
In related news, we plan to build CentOS Stream 9 with a x86-64-v2 baseline:
Building Red Hat Enterprise Linux 9 for the x86-64-v2 microarchitecture level https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level/
Thanks, Florian
On 08/01/2021 10:15, Florian Weimer wrote:
- Fabian Arrotin:
Thanks a lot for the announce, really appreciated to be aware of what's coming . I'd (myself) like to see some kind of announces being sent on the public list so that everybody can follow what's being worked on and so what to expect in Stream packages (as of course there is no official public Release Notes -yet- , appearing for RHEL, so downstream)
I'm going to let others comment on that.
Now back to the x86 cpu infra : does that mean that to *build* Stream packages (like gblic) we need at least a minimum instructions set in the CPU (builder side that is) ?
glibc itself continues to use IFUNCs on x86-64 to select optimized function implementations, based on CPU capabilities. This means that baseline x86-64 support remains sufficient for building the glibc package.
I can image that in the future, there will be some packages which build shared objects for x86-64-v3 (in addition to baseline x86-64, with run-time selection later), and which test all implementations at build time. In such a scenario, the builders would have to support x86-64-v3.
In related news, we plan to build CentOS Stream 9 with a x86-64-v2 baseline:
Building Red Hat Enterprise Linux 9 for the x86-64-v2 microarchitecture level https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level/
Thanks a lot, that's exactly the kind of information I wish we had when we started to build the new infra for Stream 9 .... now to see if what deployed as hardware for this is enough :)
On 08/01/2021 10:48, Fabian Arrotin wrote:
On 08/01/2021 10:15, Florian Weimer wrote:
- Fabian Arrotin:
Thanks a lot for the announce, really appreciated to be aware of what's coming . I'd (myself) like to see some kind of announces being sent on the public list so that everybody can follow what's being worked on and so what to expect in Stream packages (as of course there is no official public Release Notes -yet- , appearing for RHEL, so downstream)
I'm going to let others comment on that.
Now back to the x86 cpu infra : does that mean that to *build* Stream packages (like gblic) we need at least a minimum instructions set in the CPU (builder side that is) ?
glibc itself continues to use IFUNCs on x86-64 to select optimized function implementations, based on CPU capabilities. This means that baseline x86-64 support remains sufficient for building the glibc package.
I can image that in the future, there will be some packages which build shared objects for x86-64-v3 (in addition to baseline x86-64, with run-time selection later), and which test all implementations at build time. In such a scenario, the builders would have to support x86-64-v3.
In related news, we plan to build CentOS Stream 9 with a x86-64-v2 baseline:
Building Red Hat Enterprise Linux 9 for the x86-64-v2 microarchitecture level https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level/
Thanks a lot, that's exactly the kind of information I wish we had when we started to build the new infra for Stream 9 .... now to see if what deployed as hardware for this is enough :)
So if we have to start with x86-64-v2 (and eventually x86-64-v3 later one for some pkgs), I just checked all (normally) needed cpu flags and we're so "covered" .. :
for flag in sse3 sse4_2 popcnt cx16 avx2 movbe; do egrep -q ${flag} /proc/cpuinfo && echo "Flag ${flag} present !" || echo "Flag ${flag} MISSING" ; done Flag sse3 present ! Flag sse4_2 present ! Flag popcnt present ! Flag cx16 present ! Flag avx2 present ! Flag movbe present !
I was in 'panic mode' for some minutes until I was able to confirm that what we have should work .. ;-)
On Fri, Jan 8, 2021 at 3:13 AM Fabian Arrotin arrfab@centos.org wrote:
On 07/01/2021 19:04, Florian Weimer wrote:
We have rebased a large part of the glibc dynamic loader and the x86 CPU detection infrastructure to the current upstream version. These changes are going to land in CentOS Stream soon.
Hi Florian,
Thanks a lot for the announce, really appreciated to be aware of what's coming . I'd (myself) like to see some kind of announces being sent on the public list so that everybody can follow what's being worked on and so what to expect in Stream packages (as of course there is no official public Release Notes -yet- , appearing for RHEL, so downstream)
Wondering if such initiative wouldn't be good to : as development will be more and more transparent, what about also "up2date" doc about new backported features , etc ?
We're definitely encouraging people to reach out on items the community might find interesting. Florian's example is great, and we've also highlighted new application streams like postgresql 13 as they become available.
I think for now we're going to do it on an ad hoc basis until we get more of the CentOS Stream structure in place. As that gets rounded out and the contribution process gets determined, we'll need to consider how best to work this both from things the RHEL teams are working on and for things the CentOS Stream community would like to work on. In the meantime, start small, evolve :)
josh
Now back to the x86 cpu infra : does that mean that to *build* Stream packages (like gblic) we need at least a minimum instructions set in the CPU (builder side that is) ?
Kind Regards,
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-
Fabian Arrotin -
Florian Weimer -
Josh Boyer