Торвальдс с Claude Code втрое ускорил мелкие чтения в тесте

Подробно

Что именно сделал Торвальдс с помощью Claude Code?

В основном репозитории ядра Linux появилась отдельная ветка noref-filemap-read-with-llm. Её последний коммит - «mm: read from the page cache without folio references», автор и коммитер - Линус Торвальдс. Этот коммит от 10 октября 2026 года файлов не меняет: в нём только подробное описание всей серии. Изменения кода содержатся в восьми патчах под ним, у каждого стоит пометка Assisted-by: LLM.

О роли ИИ Торвальдс пишет прямо:

«Код, тестовые программы, ревью, на котором основан список проблем, и первый черновик текста сделаны с Claude Code под моим руководством; измерения запускались на моей машине».

Ветку 11 октября заметил основатель Phoronix Майкл Ларабел, пока ждал выхода Linux 7.3-rc7. По его словам, тематические ветки в основном репозитории Торвальдса появляются редко. Серия основана на Linux 7.3-rc6 с исправлениями. Какая модель Claude и какой режим Claude Code использовались, сколько было запросов и какую часть кода Торвальдс правил вручную, в описании не сказано.

Какую проблему решают патчи для page cache?

Проблема возникает, когда много потоков мелкими порциями читают один и тот же файл. Функция filemap_get_read_batch() атомарно увеличивает счётчик ссылок folio, а filemap_read() затем его уменьшает. Получается, что при каждом чтении одна и та же строка памяти struct page записывается дважды, и процессорные ядра конкурируют за неё. Обсуждение этого узкого места идёт в сообществе с 2024 года.

В новой схеме folio, удалённый из page cache, возвращается аллокатору только после RCU grace period. Благодаря этому читатель под rcu_read_lock() может скопировать данные прямо в пользовательский буфер без захвата ссылки на folio, с отключёнными page fault. Быстрый путь срабатывает не всегда. Чтение уходит на прежний путь со счётчиком ссылок в нескольких случаях:

• page fault;
• страница отсутствует или неактуальна;
• стоит метка readahead или dropbehind;
• достигнут конец файла;
• пришёл фатальный сигнал;
• нужен вызов flush_dcache_folio().

Ради сохранения гарантий четвёртый патч запрещает функции page_cache_pipe_buf_try_steal() забирать folio из page cache. FUSE и virtio_console теперь должны копировать данные.

Насколько ускорились чтения в тестах?

Все цифры - это измерения Торвальдса на одном ноутбуке: Intel Core i7-8565U (4 ядра, 8 потоков), файловая система ext4, отключены защиты CPU mitigations и CONFIG_HARDENED_USERCOPY. В основном тесте выполняется pread() размером 16 байт с нулевого смещения одностраничного файла, у каждого потока свой файловый дескриптор.

• 8 потоков, один файл: 9,9-10,4 млн чтений/с без патчей против 30-33 млн с патчами; затраты ядра упали с 2937-2975 до 725-726 тактов на чтение.
• 4 потока, по одному на физическое ядро: с 8,9-11,6 млн до 25-26 млн чтений/с; с 1318-1401 до 417-438 тактов.
• 1 поток: с 7,9-8,1 млн до 8,8-8,9 млн чтений/с; с 452-454 до 408-409 тактов, то есть обычный однопоточный сценарий тоже ускорился.
• Чтения по 64 КиБ, 8 потоков: с 17 948-18 051 до 10 925-11 146 тактов.

По данным утилиты perf c2c, при восьми потоках число событий Load HITM упало с 30 538 до 101. В исходном варианте 99,92% таких событий приходилось на строку памяти со счётчиком ссылок. Торвальдс предупреждает, что ноутбук троттлит при нагреве, поэтому надёжнее сравнивать затраты на одно чтение, а не число чтений в секунду. Для чтений по 1 МиБ при восьми потоках сравнение тактов он признал некорректным из-за разной частоты процессора. Что до более мощных систем, то, по словам Торвальдса, «ничего крупнее не измерялось».

Где новый код работает медленнее?

Замедлился один узкий случай: однопоточное чтение в пользовательскую страницу, которой ещё нет в отображении. Там 16-байтное чтение подорожало с 4117-4188 до 6543-6593 тактов. Причина - лишнее неудачное исключение перед возвратом на старый путь.

Главный компромисс связан с памятью. Страницы, удалённые из page cache, какое-то время недоступны аллокатору. Если на одном CPU в очереди скопилось больше 1024 страниц, отдельный worker вызывает synchronize_rcu_expedited(). Порог 1024 Торвальдс прямо называет предположением. В виртуальной машине с 2 ГиБ памяти без swap первые шесть патчей при 4 и 8 CPU приводили к тому, что OOM-killer завершал крупный процесс. Полная серия из восьми патчей прошла этот тест при 1, 2, 4 и 8 CPU без перехода в direct reclaim. Но в тесте hole-punch с 16 процессами в очереди всё равно ожидало в среднем 177 МиБ, а на пике до 870 МиБ.

Кроме того, найдена регрессия в CMA: alloc_contig_range() может вернуть -EBUSY, пока перенесённые страницы ждут освобождения после RCU grace period. О части восьмого патча, касающейся планировщика, Торвальдс пишет: «Я не уверен, что это правильное направление».

Насколько надёжны патчи и что не проверено?

Собственные тесты автора повреждений данных не выявили. В тесте evict-race за 30-секундные прогоны примерно по 100 млн чтений ошибок не было, в тесте partial-fault - ноль ошибок на 1,15 млн чтений. При этом не запускались xfstests, KASAN и lockdep. Не проверялись 32-битные сборки, конфигурация с CONFIG_HARDENED_USERCOPY, текущая версия серии с компилятором clang, другие модели preemption и RCU и любое другое физическое устройство.

В AI Tamer через git fetch подтвердили, что ветка существует и её вершина датирована 10 октября. Цифры производительности там считают заявлениями Торвальдса: воспроизведения на другом оборудовании не найдено. В Hardware Busters называют проблему реальным узким местом page cache, но напоминают, что код не слит и измерен на одном ноутбуке. Сорав Рудра из It's FOSS отмечает, что выигрыш получен с отключёнными защитными настройками. Публичного ревью именно этой ветки от сопровождающих подсистем памяти, RCU или планировщика пока не видно.

Попадут ли патчи в Linux 7.4?

Неизвестно. На 14 октября ветка master в репозитории Торвальдса стоит на Linux 7.3-rc7, а noref-filemap-read-with-llm остаётся отдельной веткой. В описании серии целевой версии ядра нет. Майкл Ларабел назвал прирост производительности значительным, а возможное попадание в окно слияния Linux 7.4 сформулировал как вопрос, а не как план. Будет ли архитектура доработана, заменена другим подходом или отклонена, неизвестно.

Какие подходы к этой проблеме предлагались раньше?

В мае 2024 года на саммите Linux Storage, Filesystem, Memory-Management and BPF Мэттью Уилкокс назвал захват ссылок на folio при мелких чтениях слишком дорогим и предложил использовать RCU. Участники попросили более убедительных цифр и указали на риск, что освобождение памяти будет задерживаться. Торвальдс приводит в описании серии и историческое возражение Уилкокса к такой идее: «Мне кажется слишком рискованным держать столько памяти в ожидании повторного использования».

В октябре 2025 года Кирилл Шутёмов предложил патч «mm/filemap: Implement fast short reads». В нём данные без ссылки на folio копировались во временный буфер на стеке, а затем проверялся счётчик последовательности. В ходе обсуждения нашлись гонки, которые такая проверка не ловит.

Параллельно развивается другой подход - серия «mm: improve folio refcount scalability». В марте 2026 года Торвальдс одобрил её вариант со специальным битом состояния dead/frozen. 12 сентября 2026 года Илья Гладышев опубликовал шестую версию этой серии. Эндрю Мортон счёл её результаты похожими на прежний подход fast short reads, а авторы признали, что у них нет подходящего многоядерного сервера для полноценного теста масштабируемости.