Podczas gdy okno scalania Linuksa 6.4 zamyka się w ten weekend, dzisiaj, ostatniego pełnego dnia tego okresu, Jens Axboe zgłasza wsparcie potoku FMODE_NOWAIT jako coś, co opisał jako dużą poprawę wydajności i wydajności.
Dzięki wcześniejszemu wcieleniu obsługi łatek FMODE_NOWAIT dla potoków, Axboe wyjaśnił:
„Jedną z rzeczy, która zawsze była nieco wolniejsza niż bym chciał w przypadku io_uring, jest radzenie sobie z potokami. Nie obsługują one IOCB_NOWAIT, dlatego musimy przenieść je do io-wq do obsługi. Ta seria dodaje obsługę FMODE_NOWAIT do potoków.”
Ale tam, gdzie naprawdę robi się szalenie, jest skala wzrostu wydajności/wydajności:
“Ciekawe, jak robi to dużą różnicę, napisałem mały test porównawczy, który po prostu otwiera 128 potoków, a następnie wykonuje 256 rund odczytu i zapisu do nich. Zostało to uruchomione 10 razy, odrzucając pierwsze uruchomienie, ponieważ zawsze jest nieco wolniejsze. Przed łatką:
Śr.: 262,52 ms
Stdev: 2,12 ms
Min.: 261,07 ms
Maks. 267,91 msi po zastosowaniu poprawki:
Średnia: 24,14 ms
Odch. standardowa: 9,61 ms
Min.: 17,84 ms
Maks.: 43,75 mslub około 10-krotna poprawa wydajności (i efektywności).
Przepuściłem łaty przez rury ltp i testy spawów, nie zaobserwowałem żadnych regresji. Patrząc na ślady io_uring, widzimy, że nie mamy już żadnych śladów io_uring_queue_async_work() po patchu, gdzie wcześniej wszystko było robione przez io-wq.”
Później dodano w tej serii poprawek:
„Powyższe test polegał na tym, że rura była pusta w momencie wydawania odczytu, jeśli test zostanie zmieniony tak, aby zawierał dane kiedy, wygląda to jeszcze lepiej:
Przed:
Średnia: 249,24 ms
Stdev: 0,20 ms
Min: 248,96 ms
Maks.: 249,53 msPo:
Śr.: 10,86 ms
Standardowe: 0,91 ms
Min: 10,02 ms
Maks.: 12,67 mslub około 23-krotna poprawa.”
Łatki ustawione do łączenia z Linuksem 6.4 ustawiają obsługę FMODE_NOWAIT dla potoków, ale wyłączają ją, jeśli używasz splice/vmsplice na rurze. To żądanie ściągnięcia jest teraz oczekuje na obsługę potoku FMODE_NOWAIT.
