Slajdy z Linux Plumbers Conference 2026 pokazują, że autowektoryzacja jądra Linux dla RISC-V nie daje jednakowego wyniku w każdym teście: kompresja LZ4 na ASC-X osiągnęła +15,1%, a na K3 zanotowała -7,5% względem mtune. To wstępne pomiary zależne od obciążenia i celu sprzętowego, przedstawione podczas konferencji, która odbyła się 5–7 października 2026 roku. Slajdy z wynikami rozbijają rezultaty na poszczególne operacje i platformy.
Co oznacza autowektoryzacja w jądrze
Autowektoryzacja to automatyczne przekształcanie przez kompilator odpowiednich fragmentów programu tak, by korzystały z instrukcji wektorowych — przetwarzających wiele elementów danych w jednej operacji. W eksperymencie omawianym na konferencji chodziło o użycie rozszerzenia Vector procesorów RISC-V przy kompilowaniu jądra Linux. Opis wystąpienia wskazywał na wstępny charakter pomiarów oraz wyzwania związane z zarządzaniem kontekstem niezależnym od długości wektora (VLA) i utrzymaniem kodu.
W opisywanym kontekście Vector był domyślnie wyłączony, a użycie go w jądrze wymagało jawnego zarządzania kontekstem. Wyniki w slajdach podano jako zyski względem mtune — wartości bazowej użytej w tym zestawieniu.
Wyniki zależą od obciążenia i celu
Poniższe wartości pochodzą z prezentacji i odnoszą się do wskazanych tam testów. W przypadku LZ4 kompresja i dekompresja to osobne wyniki; przy Nginx pomiary obejmują obsługę danych o rozmiarze od 80 B do 32 KB.
| Obciążenie i operacja | Cel sprzętowy | Wynik względem mtune |
| LZ4 (zram), kompresja | ASC-X | +15,1% |
| LZ4 (zram), dekompresja | ASC-X | +1,0% |
| LZ4 (zram), kompresja | K3 | -7,5% |
| LZ4 (zram), dekompresja | K3 | +9,4% |
| Btrfs (fsmeta), tworzenie | ASC-X | +5,2% |
| Btrfs (fsmeta), usuwanie | ASC-X | +8,4% |
| Btrfs (fsmeta), tworzenie | K3 | +6,9% |
| Btrfs (fsmeta), usuwanie | K3 | +3,7% |
| XFS (fsmeta), zestaw testów | ASC-X | +2,5% i +5,0% |
| XFS (fsmeta), zestaw testów | K3 | Wynik nieistotny |
| Nginx, obsługa danych 80 B–32 KB | ASC-S | +0,9% do +2,2% |
| Nginx, obsługa danych 80 B–32 KB | K3 | +0,3% do +1,9% |
Różnica między kompresją a dekompresją LZ4 jest szczególnie wyraźna na K3: pierwsza operacja wypadła gorzej, druga lepiej. Z kolei wyniki Btrfs zmieniają się zarówno między celami, jak i między tworzeniem a usuwaniem metadanych. Wartość szczytowa nie opisuje więc zachowania całego zestawu testów.
Dla testów systemowych K3 średnia geometryczna wyniosła +0,1%. Wśród ujemnych wyników znalazły się także testy procesów i wątków hackbench: odpowiednio -2,51% i -4,06%. To kontekst dla pojedynczych wzrostów z tabeli, a nie kolejny wynik tego samego testu.
Kontrole Vector w przestrzeni użytkownika to osobna sprawa
Udokumentowane przez Linux interfejsy PR_RISCV_V_SET_CONTROL i PR_RISCV_V_GET_CONTROL pozwalają zarządzać dostępnością Vector dla wątku przestrzeni użytkownika. Z kolei /proc/sys/abi/riscv_v_default_allow określa domyślną dostępność dla nowych procesów. Te ustawienia nie włączają autowektoryzacji jądra: eksperyment opisywał odrębne użycie instrukcji wektorowych wewnątrz jądra i osobne mechanizmy zarządzania jego kontekstem. Dokumentacja Linuksa dla RISC-V wskazuje też, że wywołania systemowe mogą nadpisywać rejestry wektorowe zgodnie z konwencją wywołań.
Zarządzanie kontekstem i dostrajanie pod sprzęt
Użycie rejestrów wektorowych w jądrze wymaga zapisania i przywrócenia ich stanu. W slajdach opisano użycie kernel_vector_begin() i kernel_vector_end() oraz ograniczenia w kontekstach twardych przerwań i NMI. Dla rejestrów v0–v31 tabela podaje 512 B stanu przy VLEN 128 i 4 KiB przy VLEN 1024. Opis wystąpienia wskazuje ponadto na koszty obsługi kontekstu i wyzwania związane z utrzymaniem kodu.
Przykłady dotyczące drzewa źródeł wymieniają GCC 16.1 i parametr -mtune=tt-ascalon-d8. Prezentacja omawia też osobno kompilacje lepiej dostrojone do konkretnych celów, w tym warianty nieprzenośne. Takie dostrojenie może poprawić wynik dla wybranego sprzętu, ale nie jest tym samym porównaniem co wyniki względem mtune przedstawione w tabeli.
