Phoronix poinformował, że 22 października 2026 r. zmianę optymalizującą flushowanie workqueue scalono z Linux Git dla rozwijanej linii Linux 7.4. Zgodnie z opisem flush ma odwiedzać kolejki używane od poprzedniego flushu, zamiast sprawdzać po jednej dla każdego możliwego CPU.
Co zmienia się w workqueue jądra
Workqueue to mechanizm jądra Linuksa służący do asynchronicznego odraczania pracy. Zmiana dotyczy ich flushowania, czyli przechodzenia przez kolejki podczas tej operacji. Ścieżka umieszczania pracy w kolejce pozostaje bez zmian. Chodzi o kolejki jądra, a nie o API kolejek przestrzeni użytkownika.
Dlaczego pojawia się XFS
Według relacji Phoronix Huawei engineer Yao Kai zgłosił narzut związany z przechodzeniem przez workqueue CIL systemu XFS. Przy każdym wymuszeniu zapisu dziennika kolejka ta jest flushowana; na maszynie ze 128 CPU samo jej przejście miało zajmować do 64 mikrosekund na flush.
Jak zmieniła się przepustowość w podanych testach
Phoronix przypisał poniższe wartości komunikatowi commit Tejuna Heo. Dotyczą systemu z 192 CPU i dwoma węzłami. W próbach z 16 wątkami każdy z nich umieszczał element pracy w kolejce i wykonywał flush.
| Obciążenie | Typ workqueue | Przed (flushy/s) | Po (flushy/s) | Stosunek przepustowości |
| Bezczynna | per-CPU | 40 000 | 4 200 000 | 105× |
| Bezczynna | unbound | 450 000 | 4 300 000 | ok. 9,6× |
| 16 wątków | per-CPU | 30 000 | 110 000 | ok. 3,7× |
| 16 wątków | unbound | 60 000 | 180 000 | 3× |
Wartości pokazują liczbę flushy na sekundę, czyli przepustowość, a nie czas wykonania całego zadania. Największy stosunek dotyczył bezczynnej kolejki per-CPU; pozostałe przypadki miały mniejsze, lecz nadal wyższe od początkowych wyniki.
Gęste obciążenie przyniosło inny wynik
Gdy aktywne były wszystkie workqueue w pulach, przepustowość flushowania per-CPU pozostała bez zmian, a dla unbound była niższa o 15–20%. Wyniki zależą więc od rodzaju kolejki i obciążenia, a nie każda z przytoczonych prób zakończyła się poprawą.
