Линус Торвальдс испытывает патчи Claude Code для страничного кэша Linux

Линус Торвальдс подготовил набор патчей для подсистемы управления памятью в ядре Linux. Они меняют чтение мелких блоков из страничного кэша: атомарно трогать счётчик ссылок в структуре folio больше не требуется. Для ядра это не косметика интерфейса, а правка горячего пути, по которому проходят короткие обращения к уже находящимся в памяти данным.

В тексте коммита указано, откуда взялась заготовка. Изменения, связанные с ними тесты и черновой текст примечания созданы ассистентом Claude Code, а контроль оставался у Торвальдса. Эксперимент поэтому нельзя описать ни как безлюдную генерацию, ни как обычную ручную правку: машина собрала черновик, человек держал результат.

Патчи помещены в отдельную ветку noref-filemap-read-with-llm. Перейдут ли они в основную ветку ядра, пока не сказано; не исключено, что это внутренний эксперимент. Имя ветки само фиксирует два обстоятельства — чтение из страничного кэша без счётчика ссылок и участие языковой модели.

Проверка на чтении мелких файлов дала самый крупный прирост при восьми потоках. Пропускная способность выросла с 9,9–10,4 до 30–33 миллионов операций в секунду, то есть в три раза. Именно эта конфигурация показывает, зачем затевалась оптимизация: когда читателей много, старый путь почти перестаёт быть чтением.

Четыре потока тоже ускорились, но скромнее относительно восьми. Результат сдвинулся с 8,9–11,6 до 25–26 миллионов операций в секунду, прирост в два раза. Разброс исходных цифр здесь шире, чем в восьмипоточном замере, однако новый коридор уже собран у верхней границы и не пересекается со старым.

Однопоточная нагрузка почти не изменилась: с 7,9–8,1 до 8,8–8,9 миллиона операций в секунду. Сопоставление трёх режимов важно само по себе. Если бы патч ускорял само копирование данных, выигрыш был бы виден и без соседних потоков; слабый сдвиг в одиночном режиме говорит, что узкое место было в конкуренции, а не в длине чтения.

Причина названа прямо. Одновременное обращение к страничному кэшу создаёт жёсткую конкуренцию потоков за доступ к кэшу. Когда восемь потоков пытаются одновременно читать по 16 байт, 99,92% времени уходит не на чтение, а на ожидание доступа к счётчику ссылок.

Полезная работа в таком сценарии измеряется долями процента. Вместо отдельных блокировок, изменения счётчиков ссылок или промежуточной буферизации патч использует обходной путь. Корректность держится на отложенном освобождении памяти и синхронизации через механизм RCU, Read-Copy-Update.

Читатель не захватывает страницу атомарным увеличением счётчика folio на каждую короткую операцию и не складывает данные в дополнительный буфер ради безопасности. Метод даёт конкретную гарантию. Страница памяти не будет физически освобождена, пока читающий поток не завершит копирование данных.

Отложенное освобождение здесь не ослабление контроля, а перенос проверки на момент, когда копия уже сделана. Пока поток читает, память остаётся на месте. Из этого следует и предел ожидания.

Троекратный рост на восьми потоках не отменяет почти плоский результат в один поток, а ветка noref-filemap-read-with-llm ещё не равна основной линии ядра. Пока опубликован только эксперимент под контролем Торвальдса: Claude Code подготовил патчи, тесты и черновик примечания, а вопрос о переносе остаётся открытым.