Michael Larabel z Phoroniksa czekał 11 października na wydanie Linuksa 7.3-rc7 i odświeżył repozytorium torvalds/linux.git. Zamiast samego mastera zobaczył nową gałąź o nazwie noref-filemap-read-with-llm. Końcówka „llm” w nazwie mówi sama za siebie.
W opisie serii stoi to czarno na białym: „The code, the test programs, the review behind the list above and the first draft of this text were done with an LLM coding assistant (Claude Code) under my direction. The measurements were run on my machine.” Kod, programy testowe, przegląd zmian i pierwszy szkic opisu zrobił Claude Code, pomiary Torvalds puścił na własnej maszynie. Każdy commit ma pod spodem linijkę Assisted-by: LLM, tuż obok Signed-off-by.
Co poprawiają łatki Torvaldsa w page cache
Problem siedzi w filemap_read(). Funkcja bierze i oddaje referencję na każdym folio, z którego kopiuje dane, więc gdy wiele procesorów czyta drobne kawałki tego samego pliku, wszystkie walczą o jeden licznik. Seria robi odczyt z pamięci podręcznej bez brania referencji. Żeby to było bezpieczne, folio wyjęte z page cache zwalnia się dopiero po okresie karencji RCU (grace period), czyli wtedy, gdy żaden czytelnik nie może już na nie patrzeć.
Ile daje łatka? Liczby z Threadrippera 3970X
Torvalds mierzył na Threadripperze 3970X (32 rdzenie, 64 wątki). Test to 16-bajtowy pread() z jednostronicowego pliku na btrfs, każdy wątek z własnym deskryptorem, przebiegi po 5 sekund, po trzy na wariant. „Przed” to jądro 7.3-rc6, „po” to ta sama wersja z całą serią.
| Wątki | Odczyty/s przed | Odczyty/s po | Cykle na odczyt przed | Cykle na odczyt po |
|---|---|---|---|---|
| 1 | 7,4–7,6 mln | 7,7–7,8 mln | 503–505 | 479–492 |
| 8 (8 rdzeni) | 16,7 mln | 60,5 mln | 1973–1981 | 477 |
| 32 (32 rdzenie) | 13,4–13,7 mln | 236–237 mln | 9805–9950 | 478 |
| 64 | 13,3 mln | 304 mln | 19857–19939 | 735–736 |
Na 32 rdzeniach odczyt współdzielonego pliku kosztuje teraz tyle, co przy jednym wątku, a wcześniej kosztował dwadzieścia razy więcej. Na 64 wątkach jest 23 razy więcej odczytów za 1/27 cykli. Resztę narzutu Torvalds tłumaczy hyperthreadingiem, bo dwa wątki dzielą wtedy jeden rdzeń. Jest też cena: odczyt do strony użytkownika, której nie ma w pamięci, łapie wyjątek dwa razy. Taki 16-bajtowy odczyt kosztuje 6022–6296 cykli zamiast 4397–4428.
Pierwsza wersja kończyła się OOM-killerem
Gałąź z „llm” w nazwie to już historia. Pierwsza wersja ustawiała flagę opóźnionego zwalniania na każdym folio wyjętym z page cache. Kiryl Shutsemau sprawdził to na maszynie wirtualnej z 64 procesorami i 2 GB pamięci i dostał OOM-killera: za dużo pamięci czekało na koniec okresu karencji, przy dziurawieniu plików na tmpfs i przy odzyskiwaniu pamięci, nawet bez żadnego gorącego folio w obciążeniu. W repozytorium wisi teraz gałąź rcu-free-v3 z 12 i 13 października: dziesięć commitów, flaga trafia tylko na folio, do których odczyty ciągle wracają, a jądro liczy strony czekające na zwolnienie i zwalnia je przed OOM. Sam pomysł z oznaczaniem tylko gorących folio i oba warunki, po których się je rozpoznaje, pochodzą z gałęzi Shutsemaua. Wszystkie dziesięć commitów nadal ma Assisted-by.
Tego samego weekendu w repozytorium pojawił się też tag assoc-array-fixes. Nils Ollrogge zgłosił błąd w bibliotece tablic asocjacyjnych razem z poprawką, ale kod był dla Torvaldsa zbyt zawiły. Rozbił go więc z pomocą modelu na mniejsze funkcje i przepuścił przez testy w przestrzeni użytkownika. Testy potwierdziły zgłoszony błąd i znalazły trzy kolejne, siedzące w kodzie od pierwszego commitu biblioteki z 2013 roku.
Czy łatki trafią do Linuksa 7.4?
Na 20 października nic z tego nie jest w masterze. Phoronix stawia na okno łączenia Linuksa 7.4, które otworzy się po wydaniu 7.3. Na amigowej scenie dopisek „AI tego nie pisało” w README robił za dowód niewinności, a tu autor jądra sam podpisuje, z czego korzystał. Ciekawsze od samego Claude Code jest jednak co innego: maszyna napisała szybki kod, a człowiek z listy mailingowej znalazł w nim OOM. Recenzja zadziałała tak, jak powinna.
