| ikey | |
| Oct 10 2017, 3:26 AM |
| F3526016: 0001-Exclude-unwanted-paths-from-libdirs-for-initrd-creat.patch | |
| Jun 3 2018, 1:01 PM |
Enable an AVX2 build of glibc core libraries.
Note - the dynamic linker itself should be omitted from the avx2 directory, but the core glibc libs (math, etc) should have an AVX2 variant by
default to squeeze some extra juice out of the system.
At some point we should also do the same to Mesa, but this will require us to first move to glvnd and ypkg-ify our mesa, moving legacy comar
out to kernel-glue.
| R927 glibc | |||
| R927:21f725c3a941 Enable AVX2 libs, resolves T4719 | |||
Also as compatibility for the future glibc upgrades (which actually has a regression with this upstreamed behaviour) we'll need to make sure we refer to this
internally as Haswell enabling for the extra libset.
This will be important I think. Whether you want to exclude them when doing initrd, so it can be booted on any CPU as I imagine a few of the tools will be high on my list of in terms of things like zlib/gcc math libs which are also great targets for avx2.
T4522 links to the patch that fixes upstream behaviour. But I do want those proper patches as they check against all CPU extensions added so no false positives which may have occurred using -march=haswell with our current method.
Also, when thinking in terms of tooling changes: It would be pretty swell to have a method to sort out libs not in %libdir% /usr/lib64/R/lib/libR.so as the first example that comes to mind.
Whether in the tooling itself (adding the path to the pattern) to work without patching the code to find it would be quite a boost if it's possible through RPATH and picking up the haswell/lib dir automagically.
The other case is dlopen where it's much easier to change the path (if patching the code) via an extension, rather than inserting haswell into the path.
@livingsilver94 this'd be a special build that sits in /usr/lib64/avx2 for AVX2 capable CPUs. Right now glibc will be using SSE - which is probably better for most people in most
situations tbh.
@ikey So I've targeted down dracut in order to solve our kernel issues. There are two issues:
This is actually broken if you ship /usr/lib64/haswell/avx512_1 libraries and build on an AVX512 machine, but I imagine, we simply want to ship 1 global version to reduce space:
https://github.com/dracutdevs/dracut/blob/master/install/dracut-install.c#L330 has the two functions resolve_deps which calls library_install and is the one installing the two versions of the libraries.
https://github.com/dracutdevs/dracut/commit/791532b0ce833614910d1d405c0238938408bd6b is the commit that added installing the 2 versions of the libraries into the initrd.