Linus Torvalds slibuje 3× rychlejší čtení v Linuxu. Změřil to jen na notebooku

Tvůrce Linuxu dlouhodobě patří k nejvlivnějším hlasům o tom, jak se software vyvíjí. Když se v jeho hlavním repozitáři torvalds/linux.git objeví nová vývojová větev, komunita si jí všimne; jak upozorňuje server Phoronix, Torvalds tam obvykle větve nevede a hostuje jen hlavní linii. Letos v sobotu 10. října v ní přibyla větev s výmluvným názvem noref-filemap-read-with-llm. Přípona „llm" nebyla náhoda: v popisu patchů Torvalds přímo přiznává, že práci odvedl kódovací asistent Claude Code od společnosti Anthropic, a to pod jeho vedením.

Obsah větve přitom není žádná drobnost. Jde o sadu osmi patchů postavených nad jádrem 7.3-rc6, které mění práci s page cache, tedy stránkovou mezipamětí, v níž jádro drží data čtených souborů. Cílem je číst z ní bez braní folio referencí, což má odstranit úzké hrdlo, které se projevuje právě tehdy, když mnoho vláken najednou čte jeden soubor po malých kouscích. To je scénář typický pro servery: webové aplikace čtou konfigurace a session soubory, mailové servery prohledávají schránky, kontejnery si sdílejí stejné knihovny.

Proč je malé čtení problémem

Každé čtení z page cache si u folia, tedy reprezentace skupiny stránek v paměti, nejprve vezme referenci a po skončení ji zase pustí. Obojí je atomická operace nad stejným počítadlem, takže každé čtení tuhle cachovou linii zapíše dvakrát. Při jednom vlákně to nevadí, ale když ten samý soubor čte osm vláken, přestane počítadlo stíhat a vlákna na něm začnou navzájem čekat. Matthew Wilcox, dlouholetý správce kódu page cache, problém popsal už v roce 2024 v souvislosti se zátěží jednoho zákazníka.

Torvalds to změřil na svém notebooku s procesorem i7-8565U (čtyři jádra, osm vláken), kde osm vláken četlo 16 bajtů z jedné stránky. 99,92 % všech zaznamenaných kolizí typu HITM, tedy situací, kdy jádro čeká na data držená jiným jádrem, připadlo na jedinou cachovou linii s tím počítadlem. Jinými slovy, téměř veškerá práce čtyř jader se v tomto scénáři ztrácela v čekání na jediný sdílený čítač.

Jak má oprava fungovat

Nápad sám je popsán jednou větou: folio vyjmuté z page cache se zpět do alokátoru paměti vrátí až po takzvané RCU grace period, tedy v období, kdy jádro počká, až skončí všichni čtenáři, kteří si daná data mohli právě prohlížet. Čtenář pod zámkem rcu_read_lock() pak může najít stránku v cache a kopírovat z ní přímo do uživatelského bufferu. Bez braní reference, bez pomocného bufferu na zásobníku, bez pořadového čísla a bez následné kontroly, jestli se stránka mezitím nezměnila.

Není to první pokus o takovou optimalizaci. Torvaldsova starší varianta z roku 2024 a „fast short reads" od Kirilla Shutemova kopírovaly data bez reference do dočasného bufferu a důvěryhodnost výsledku ověřovaly až dodatečně. Selhaly ale na případech, které dodatečná kontrola nevidí: když je stránka mezitím uvolněna, znovu použita a dokonce znovu vložena na stejné místo, při migraci, nebo když už tam data page cache vůbec nejsou. Odklad uvolnění stránky tyto případy místo odhalování rovnou odstraňuje.

Osm patchů se dělí na dvě části. Prvních šest zavádí samotný mechanismus: příznak PG_rcu_free, per-CPU fronty a dávkové uvolňování po skončení grace period; jeden z nich navíc zavírá vedlejší cestu, kterou šlo stránku z page cache odebrat a předat jinam. Zbývající dva řeší vedlejší efekt, který tím vzniká: když CPU uvolňuje stránky rychleji, než stíhají probíhat grace periody, začne se fronta plnit. Nad 1024 čekajících stránek na jednom CPU se proto spustí zrychlená synchronizace, která frontu zkrátí. Uvolňování stránek souborů, které se právě mažou celé, odkladu podléhat nebude, aby mazání velkého souboru neplnilo fronty zbytečně.

Čísla z jednoho notebooku

Torvalds v popisu uvádí měření pro 16bajtové čtení na začátku jednostránkového souboru, každé vlákno má vlastní deskriptor:

• 8 vláken čtoucích jeden soubor: 9,9–10,4 milionu čtení za sekundu u základního jádra, 30–33 milionů se sadou patchů, tedy zhruba trojnásobek.
• Jedno vlákno: 7,9–8,1 milionu čtení za sekundu proti 8,8–8,9 milionu, zlepšení kolem deseti procent.
• Kolize HITM při osmi vláknech: ze 30 538 na 101, tedy prakticky vymizení sdílené kolize.
• Čtení po 64 KiB osmi vlákny z jednoho souboru: jádrové cykly na jedno čtení klesly zhruba o 39 %, z přibližně 18 000 na 11 000.

Čísla je ale nutné číst s doslovně přiznanými podmínkami: jde o jediný notebook, souborový systém ext4, vypnuté hardwarové mitigace i vypnutou kontrolu CONFIG_HARDENED_USERCOPY. Notebook navíc při zátěži škrtí kvůli teplotě, takže Torvalds doporučuje porovnávat náklady na jedno čtení, ne čtení za sekundu. Stroj s více procesory nebo více sockety by podle něj měl získat ještě víc, nic většího ale měřeno nebylo. Popis také počítá s tím, že čtení do uživatelského bufferu, který ještě není v paměti, stojí jednu neúspěšnou stránkovou chybu navíc: u 16bajtového čtení jedním vláknem vzrostly cykly z asi 4 100 na 6 600.

Přiznaná rizika a otevřené otázky

Nejužitečnější částí popisu může být otevřený seznam toho, co není vyřešeno. Alokátor paměti totiž o čekajících stránkách neví, nejsou v žádném počítadle volné paměti ani na seznamech. Když je paměti málo, může proto rozhodovací logika chybně dojít k závěru, že volné paměti není dost, a spustit OOM killer, tedy zabíjení procesů, a to i tehdy, když stovky megabajtů čekají jen na uvolnění. Torvalds ukazuje reprodukční test, ve kterém bez posledních dvou patchů killer skutečně zasáhl; s nimi test proběhl čistě. Stejná neviditelnost znamená, že funkce alloc_contig_range() vrací chybu a rezervace CMA ve stavu série regresuje.

Paměť čekající na uvolnění je také sama o sobě rizikem. Wilcoxova dávná námitka zní, že je to prostě příliš riskantní, mít tolik paměti čekající na opětovné použití. Při extrémní zátěži, kdy procesy ve smyčce plní a uvolňují paměť rychlostí přes 20 GiB/s, dosahovaly špičky čekající paměti až 870 MiB u šestnácti procesů, při průměru 177 MiB. U běžnějších operací, jako je zkrácení 256 MiB souboru, čekalo nejvýše 208 MiB a do 25 milisekund zmizelo.

Testování mělo jasně ohraničené hranice: vlastní zátěžové testy prokázaly nulový počet chybných čtení, konkrétně 30sekundové běhy po zhruba 100 milionech čtení, ale vše běželo na jediném stroji a jediné konfiguraci jádra, bez ladicích vrstev lockdep a KASAN. Testovací sada xfstests spuštěna nebyla; u pokusu z roku 2024 v ní navíc dva testy selhávaly. Nevyřešené zůstávají i okrajové oblasti, od jednoho příznaku stránky navíc přes zásah do splice a chování na architektuře s390 až po neměřené náklady uvolňování mimo samotnou čtecí cestu.

Claude Code jako nástroj, rozhodnutí zůstávají u člověka

Nejcitlivější téma celého příběhu řeší Torvalds jedním odstavcem v popisu patchů: „Kód, testovací programy, revize za seznamem výše i první verze tohoto textu vznikly s LLM kódovacím asistentem (Claude Code) pod mým vedením. Měření jsem spouštěl na svém stroji." Je to překlad, originál zní „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."

Formulace je pečlivá. Asistent napsal kód, testy i draft textu, ale pod vedením, měření proběhla na Torvaldsově stroji a odpovědnost za publikaci zůstává u něj. Sedí to s jeho dřívějšími vyjádřeními, kdy AI popisoval spíše jako užitečný nástroj než hrozbu, používal ji při ladění jádra a vyzkoušel si i takzvaný vibe coding v nástroji Google Antigravity. Víkendová práce v tom nepokračuje jen jednou větví: hned vedle ní vznikl i tag assoc-array-fixes, u něhož Torvalds napsal, že udělal, co káže, a nechal LLM nástroje rozebrat pro něj nepřehledný kód asociativních polí. Uživatelská testovací sada pak potvrdila nahlášenou chybu a našla tři další, které tam jsou od prvního commitu knihovny z roku 2013. AI tedy v tomto případě nepsala jen nový kód, ale pomohla odhalit přes deset let přehlížené chyby, což podobně jako nedávný audit, kdy model Claude Mythos našel kritické chyby přímo v Linuxu a OpenBSD, ukazuje, kde mají velké modely při hledání chyb skutečně sílu.

Dostane se to do Linuxu 7.4?

O tom zatím rozhodnuto není. Série končí pozvánkou „co bych rád nechal prověřit očima ostatních" a sama jmenuje oblasti, kde potřebuje práci, od viditelnosti odložené paměti pro alokátor po návrh řešení pro CMA. Přechodová okna jádra se otevírají pravidelně; jestli sadu Torvalds zařadí do příprav verze 7.4, nebo ji nechá zrát dál, ukážou nejbližší týdny. Přinese-li nakonec změna slíbené zlepšení i na větších strojích, pocítí ji především servery, kde mnoho vláken soupeří o stejné soubory. Běžný uživatel na změnu bude čekat déle: do distribucí se jádro 7.4 dostane až řadu měsíců po vydání.

Zdroje: popis patch série ve větvi noref-filemap-read-with-llm v repozitáři torvalds/linux.git (git.kernel.org), Phoronix, 11. října 2026 a Phoronix, 12. října 2026. Výkonnostní čísla pocházejí z měření Linuse Torvaldse uvedených v popisu patch série, ne z nezávislého testu.