W wydaniu Fedora 42, planowanym na koniec kwietnia, zaproponowano umożliwienie maintainerom dołączania dodatkowych wersji plików wykonywalnych do pakietów, zbudowanych z włączeniem optymalizacji dla mikroarchitektur x86-64-v2, x86-64-v3 i x86-64-v4. Zaznacza się, że Fedora nadal zbiera pakiety dla architektury x86-64-v1, podczas gdy CentOS wykorzystuje architekturę x86-64-v2, a RHEL 10 — x86-64-v3. W większości przypadków przyrost wydajności w przypadku budowy dla takich architektur nie przekracza 10%, ale w niektórych sytuacjach prowadzi do zauważalnego wzrostu wydajności (do 120%). Propozycja nie została jeszcze zatwierdzona przez komisję FESCo (Fedora Engineering Steering Committee), odpowiedzialną za techniczną część rozwoju dystrybucji Fedora.
W Fedora już dopuszczono dostarczanie dodatkowych bibliotek, zoptymalizowanych dla rozszerzonych wersji architektury x86_64, a podobną możliwość teraz planuje się rozszerzyć na pliki wykonywalne. Ładowanie zoptymalizowanych implementacji bibliotek odbywa się za pomocą ładowarki dynamicznej (dynamic linker), która sprawdza dostępność dodatkowych wersji w podkatalogach glibc-hwcaps, umiejscowionych w obszarach FS przeszukiwanych podczas wyszukiwania bibliotek (na przykład /usr/lib64/glibc-hwcaps/x86-64-v2).
W przypadku plików wykonywalnych proponuje się użycie warstwy hwcaps-loader, która będzie wybierać i uruchamiać wersję pliku wykonywalnego, odpowiadającą możliwościom aktualnego systemu. Dla pakietów dostarczających kilka wersji plików wykonywalnych proponuje się expose tę warstwę za pomocą dowiązania symbolicznego. Decyzję o dodaniu dodatkowo zoptymalizowanych plików wykonywalnych podejmą maintainerzy, w zależności od wyników testów wydajnościowych konkretnych pakietów.
Wersje x86-64-v* określają nieoficjalny sposób identyfikacji poziomów stanu mikroarchitektury, obejmujących określone zestawy rozszerzeń:
- x86-64-v2 obejmuje rozszerzenia SSE3, SSE4_2, SSSE3, POPCNT, LAHF-SAHF i CMPXCHG16B.
- x86-64-v3 — AVX, AVX2, BMI2, FMA, LZCNT, MOVBE i SXSAVE.
- x86-64-v4 — AVX512F, AVX512BW, AVX512CD, AVX512DQ i AVX512VL.
Dodatkowo warto zaznaczyć propozycję unifikacji aktualizacji bootloaderów grub i shim w atomowych oraz klasycznych wariantach Fedory. Zamiast aktualizować zawartość katalogów /boot i /boot/efi poprzez wywołanie skryptu podczas instalacji pakietu rpm, proponuje się użycie narzędzia bootupd do aktualizacji bootloadera, które już jest stosowane w atomowo aktualizowanych wariantach Fedory. W pakietach rpm z bootloaderami zawartość proponuje się instalować nie bezpośrednio do katalogów /boot i /boot/efi, lecz do osobnego katalogu wewnątrz partycji /usr, po czym synchronizować z nim zawartość /boot i /boot/efi. Takie podejście umożliwi realizację zapasowego wariantu rozruchu, który można wykorzystać do powrotu do starej konfiguracji w przypadku problemów po aktualizacji bootloadera.
Źródło: opennet.ru
