Линус Торвальдс поручил ИИ Claude Code написать изменения для одной из важнейших подсистем ядра Linux и получил трёхкратное ускорение чтения небольших блоков данных в тестах. Разработчик открыто признал авторство нейросети, но предупредил, что экспериментальный код пока не готов для включения в основное ядро.
10 октября создатель Linux опубликовал набор изменений для подсистемы управления памятью. Восемь патчей подготовлены с помощью Claude Code, инструмента компании Anthropic для программирования. Торвальдс прямо указал, что ИИ написал код, тестовые программы, подготовил разбор известных проблем и первый черновик описания. Сам разработчик руководил работой и проводил измерения на собственном компьютере.
Изменения затрагивают страничный кэш Linux, который хранит недавно прочитанные данные файлов в оперативной памяти, чтобы не обращаться повторно к накопителю. Разработчики давно знали о проблеме производительности при одновременном чтении небольших фрагментов одного файла несколькими потоками. Узким местом оказался не поиск информации и даже не копирование байтов, а механизм учёта обращений к страницам памяти.
При каждом чтении ядро увеличивает счётчик ссылок на страницу памяти, а после завершения операции уменьшает его. Такие действия помогают предотвратить преждевременное освобождение памяти, пока программа работает с данными. Однако при одновременных обращениях разных процессорных ядер атомарные операции со счётчиком начинают мешать друг другу, поскольку ядрам приходится постоянно согласовывать изменения одной области памяти.
Торвальдс обнаружил, что при чтении 16 байт из одного файла восемью потоками на ноутбуке с Intel Core i7-8565U конкуренция за счётчик ссылок стала причиной 99,92% зарегистрированных событий передачи изменённой строки кэша между ядрами. Показатель относится именно к событиям Load HITM, а не к доле общего времени выполнения программы. Тем не менее измерения показали, насколько дорого обходится синхронизация при такой нагрузке.
Подготовленные Claude Code патчи позволяют читать данные без постоянного изменения счётчика ссылок. Вместо прежней схемы применяется механизм RCU (Read-Copy-Update), который откладывает повторное использование освобождаемой памяти до завершения критических участков чтения. Даже если страницу уже исключили из файлового кэша, ядро не отдаст соответствующую память под другие данные, пока читатель, защищённый RCU, не завершит работу.
Результаты оказались впечатляющими. При одновременной работе восьми потоков производительность выросла с 9,9–10,4 млн до 30–33 млн операций чтения в секунду. Четыре потока на отдельных физических ядрах вместо 8,9–11,6 млн выполняли 25–26 млн операций. Один поток ускорился значительно скромнее, с 7,9–8,1 млн до 8,8–8,9 млн чтений в секунду. Количество процессорных циклов на операцию при восьми потоках сократилось примерно с 2950 до 725.
Дополнительные измерения подтвердили, что изменение устраняет именно конкуренцию между процессорными ядрами. Число событий Load HITM в тесте с восемью потоками упало с 30 538 до 101. Торвальдс предполагает, что на многопроцессорных серверах выигрыш может оказаться ещё заметнее, но пока не проверял гипотезу. Все опубликованные результаты получены на одном ноутбуке с четырьмя физическими ядрами и восемью потоками, файловой системой ext4 и отключёнными некоторыми защитными механизмами ядра.
У ускорения обнаружилась обратная сторона. Отложенное освобождение страниц способно увеличить расход оперативной памяти, особенно когда программы интенсивно создают и удаляют данные. В одном из испытаний ранней версии патчей система с 2 ГБ оперативной памяти преждевременно запускала механизм OOM Killer, который принудительно завершает процессы при нехватке памяти. Дополнительные изменения позволили пройти проверку, однако полностью проблему учёта ожидающих освобождения страниц не решили.
Торвальдс также зафиксировал замедление отдельного сценария чтения. Если нужная страница пользовательского буфера отсутствует в оперативной памяти, новый алгоритм сначала предпринимает неудачную попытку копирования, после чего возвращается к прежнему механизму. В таком тесте затраты выросли примерно с 4100 до 6500 процессорных циклов. Для обычных операций чтения выигрыш может перевесить накладные расходы, но итог зависит от характера нагрузки.
Проверки выявили и другие нерешённые вопросы. Отложенное освобождение мешает некоторым операциям выделения непрерывных областей памяти, меняет поведение отдельных механизмов передачи данных и требует дополнительного анализа на архитектуре s390. Неизвестны также затраты процессорного времени на массовое освобождение страниц при длительной нагрузке. Торвальдс перечислил проблемы в описании изменений и предложил другим разработчикам изучить спорные решения.
Несмотря на успешные локальные испытания, патчи ещё не прошли полноценную проверку. Разработчик не запускал стандартный набор файловых тестов xfstests, не использовал KASAN для поиска ошибок доступа к памяти и не проверял 32-битные сборки. Не проводились испытания на других компьютерах и с некоторыми конфигурациями ядра. Для настолько чувствительной подсистемы, как управление памятью, подобные ограничения пока не позволяют считать новый алгоритм готовым к широкому применению.
Работа над ускорением небольших операций чтения началась задолго до появления нынешней серии патчей. Ещё в 2024 году разработчик ядра Мэтью Уилкокс обратил внимание на проблему в реальной пользовательской нагрузке. Последующие попытки устранить лишние операции со счётчиками ссылок сталкивались с опасными сценариями повторного использования памяти. Новый подход пытается решить проблему иначе, предотвращая преждевременное повторное использование страницы вместо проверки корректности уже скопированных данных.
Экспериментальная серия размещена в отдельной ветке noref-filemap-read-with-llm, созданной на основе Linux 7.3-rc6 с дополнительными исправлениями. В основную ветку ядра изменения пока не включены, а сроки возможного принятия неизвестны. Торвальдс даже признал, что не уверен в правильности некоторых архитектурных решений и предпочёл бы избежать вмешательства в планировщик ради ускоренного освобождения памяти.
Для Linux эксперимент интересен не только результатами тестов, но и способом разработки. Создатель ядра доверил Claude Code работу с низкоуровневыми механизмами управления памятью, где ошибка может привести к повреждению данных, сбою системы или появлению уязвимости. При этом Торвальдс не скрывал участие ИИ и подробно перечислил ограничения предложенного решения. Пока опубликованные результаты доказывают лишь возможность существенного ускорения конкретного сценария, а не трёхкратный прирост производительности Linux в целом.