Торвалдс прати първия си AI патч: 23x в тест

Линус Торвалдс публикува първата си серия патчове за Linux ядрото, писана с помощта на езиков модел. Клонът noref-filemap-read-with-llm се появи в неговото хранилище на 10 октомври, докато той подготвяше 7.3-rc7, а в придружаващото писмо той посочва изрично инструмента: Claude Code. Преработената версия на серията дава до 23 пъти по-висока пропускателна способност в синтетичен тест — число, за което сам Торвалдс предупреждава, че няма да го видите при реално натоварване.

Какво решава патчът

Проблемът е стар и добре познат. Когато много ядра четат по малко от един и същ файл, те се блъскат върху броячите на референции на folio-тата в page cache. Атомарната операция по един и същ брояч от десетки CPU превръща кеширано четене — операция, която по принцип е почти безплатна — в състезание за една линия от кеша. Бутилковото гърло е описано още през 2024 г. от Matthew Wilcox от Oracle, след като изскача в работен товар на клиент.

Решението на Торвалдс заобикаля самото взимане на референция. Четенето минава в RCU секция, а folio-тата, които напускат page cache, не се връщат веднага на алокатора: нов флаг PG_rcu_free ги задържа в per-CPU списък, докато изтече RCU grace период. Така копирането към потребителското пространство става без нито един атомарен инкремент и без bounce буфер.

В писмото си Торвалдс не оставя място за догадки кой е писал кода: „Кодът, тестовите програми, ревюто зад списъка по-горе и първата чернова на този текст бяха направени с LLM кодиращ асистент (Claude Code) под мое ръководство. Измерванията са правени на моята машина.“

Снимка: Krd / Wikimedia Commons, CC BY-SA 4.0

Числата: 3x на лаптоп, 23x на Threadripper

Първият вариант от осем патча, базиран на 7.3-rc6, е мерен на лаптоп с Core i7-8565U (4 ядра, 8 нишки, с изключени mitigations). При осем нишки, четящи един файл, пропускателната способност скача от около 10 на 30–33 милиона четения в секунда, а циклите на четене падат от ~2950 на ~725. Най-красноречив е броят load HITM събития в perf c2c — от 30 538 на 101, тоест контенцията практически изчезва. Еднонишковият случай печели скромните 10%: от 452 на 408 цикъла.

Големите числа идват от следващата ревизия, rcu-free-v3 — серия от десет патча, мерена на 64-нишков Ryzen Threadripper. Там осем нишки минават от 13,3 на 304 милиона четения в секунда, а циклите на четене падат от близо 20 000 на 735. Това е 23-кратното ускорение от заглавията, както отбелязва Tom’s Hardware. Уговорката е съществена: тестът е нарочно изроден — микроскопични четения от един файл по всички ядра — и никой истински товар няма такъв профил. Бази данни, web сървъри и споделени библиотеки ще усетят нещо, но много по-малко.

Ревюто намери race condition

Кодът не е слят и засега няма да бъде. Kiryl Shutsemau откри race в filemap_read_rcu_batch(): подмяна на folio, последвана от увеличаване на i_size, може да покаже на потребителя данни, които никога не са били записвани. Торвалдс предложи четенето на размера на файла да се премести по-рано и проверките на folio-тата да се обединят, но и Wilcox, и Shutsemau имат по-дълбоки възражения срещу схемата за освобождаване на паметта зад PG_rcu_free. Самият Торвалдс нарича отложеното освобождаване „най-малко решената част“ от серията — два от патчовете са предпазни клапи, които форсират ускорен grace период, щом опашката надхвърли 1024 страници.

Развитието вече е предадено на Shutsemau, който и преди е работил по същото бутилково гърло. The New Stack описва случая точно така: моделът е свършил работата по писането, а хората са намерили грешката, която не се вижда от бенчмарк.

Контекстът: политиката на ядрото

Ходът е логично продължение на линията, която Торвалдс защитава от месеци. Ядрото вече има официален документ Documentation/process/coding-assistants.rst, а изискването всеки LLM-подпомогнат commit да носи таг Assisted-by: беше отменено — на практика защото AI помощта стана прекалено обичайна, за да се отчита поотделно. Паралелно поддържащите пуснаха бот за ревюта и ползват чужди модели за преглед на патчове. Торвалдс е ползвал AI и по-рано, при дебъгване на драйвера Intel Xe, но това е първият път, в който подписва цяла серия, писана от асистент.

Темата не е нова и извън ядрото: наскоро Epic пусна лаунчър, писан от AI агенти, а дебатът кой носи отговорността за грешките върви успоредно с него. При Linux отговорът поне е ясен: подписът под патча е човешки, а уязвимостите в мрежовия код на ядрото показват колко скъпо излиза пропуснат детайл в mm или net слоя.

Заключение

Двете неща са верни едновременно. Торвалдс наистина получи работещ прототип за проблем, който стоеше две години, и наистина го получи по-бързо, отколкото ако го беше писал сам. И въпреки това серията не влиза в ядрото без човешко ревю, защото точно хората откриха дупката. Ако rcu-free-v3 стигне до mainline — най-рано в следващ merge window — ускорението при вашите файлови четения ще се мери в проценти, не в пъти. Детайлите по подхода и първите измервания може да проследите в публикацията на Phoronix и в разбора на Linuxiac.