Линус Торвальдс, создатель Linux и главный руководитель разработки ядра, использовал инструмент Anthropic Claude Code, чтобы помочь устранить существующее более двух лет узкое место в тракте чтения файлов. Серия из 10 патчей обеспечила 23-кратное повышение скорости чтения в синтетическом тесте на 64-ядерном процессоре Threadripper, однако позднее рецензенты ядра Linux обнаружили состояние гонки и подняли вопросы о безопасности конструкции восстановления памяти, а это означает, что патчи ещё не объединены с ядром.
Проблема со счётчиками ссылок на память страниц
Работа связана с конкуренцией за счётчики ссылок объектов, известных как folio, внутри page cache — слоя, который хранит прочитанные из файлов данные для ускорения доступа к ним. Об узком месте сообщили в 2024 году после того, как оно проявилось в рабочей нагрузке одного из клиентов. Тесты на ноутбуке Торвальдса показали, что эта конкуренция составляла 99,92% операций HITM между ядрами в тесте с использованием восьми потоков.
Торвальдс сказал, что 18 месяцев запускал ошибочную версию своего предыдущего исправления проблемы, тогда как другие разработчики сталкивались с проблемами в своих попытках. Новые патчи нацелены на удаление операций увеличения и уменьшения ссылок на folio из наиболее часто используемого пути чтения из кэша. При этом Торвальдс предупредил, что в реальных рабочих нагрузках выигрыш будет значительно меньше по сравнению с синтетическим тестом.
Роль Claude Code и ограничения результата
В дереве Торвальдса появилась экспериментальная ветка с названием noref-filemap-read-with-llm, после чего серия патчей включила объяснение роли Claude Code. По словам Торвальдса, инструмент написал реализацию, тесты и первоначальную документацию, а также проверил код под его руководством, тогда как сам Торвальдс выполнял тесты производительности.
Первая серия повысила скорость чтения на его ноутбуке примерно с 10 миллионов до 33 миллионов операций чтения в секунду и снизила число тактов ядра на одно чтение примерно с 2 950 до 725. Доработанная серия повысила производительность на Threadripper с 13,3 миллиона до 304 миллионов операций чтения в секунду под высокой нагрузкой, при этом число тактов на одно чтение снизилось примерно с 20 000 до 735.
Почему одних показателей производительности недостаточно?
Повышение производительности сопровождалось потенциальными издержками. Первая реализация вводила принудительное ожидание, когда процессор превышал порог в 1 024 страницы, ожидающие восстановления. Кроме того, чтение несвязанных пользовательских страниц приводило к дополнительной ошибке перед возвратом к существующему пути, из-за чего стоимость однопоточного чтения объёмом 16 байт выросла примерно с 4 150 до 6 550 тактов. Пока неясно, сохранится ли этот регресс в версии rcu-free-v3.
Проверка выявила наиболее серьёзную опасность
Matthew Wilcox выступил против использования нового флага PG_rcu_free и предложил альтернативу, основанную на типе страницы и другом механизме восстановления неактивных folio. Kiryl Shutsemau также предложил ограничить использование флага 64-битными системами; это направление поддержал David Hildenbrand.
Shutsemau также обнаружил состояние гонки в функции filemap_read_rcu_batch(): замена folio с последующим увеличением размера файла может привести к раскрытию данных, которые фактически не были записаны. Торвальдс предложил считывать размер файла раньше и объединить операции проверки; это было включено в доработанный патч.
Редакционный вывод certi.news: этот случай показывает, что инструменты программирования на основе искусственного интеллекта способны быстро находить значительные улучшения в тестах ядра, но не отменяют необходимость специализированной проверки, учитывающей вопросы параллелизма и жизненного цикла памяти. Приведённые рекордные показатели подтверждают выигрыш в конкретной среде, но не означают автоматической готовности к слиянию или гарантии корректности реализации.