Торвальдс использовал Claude Code для оптимизации ядра Linux. Код ускорил чтение в 23 раза, но не прошёл проверку

1 час назад 3

Линус Торвальдс подключил Claude Code к работе над ядром Linux и получил впечатляющий результат: в синтетическом тесте скорость чтения из кеша выросла почти в 23 раза. Правда, при проверке изменений разработчики обнаружили состояние гонки и проблемы с управлением памятью. Теперь решение дорабатывают, а история стала показательным примером того, как ИИ справляется с задачами системного программирования.

Проблема, которую пытались решить два года

Всё началось с узкого места в работе страничного кеша Linux. Когда несколько потоков одновременно читают один и тот же файл, ядро использует счётчик ссылок на блок памяти — folio. При каждом чтении этот счётчик приходится увеличивать, а затем уменьшать.

При высокой параллельной нагрузке потоки начинают конкурировать за одну и ту же строку кеша процессора. В результате значительная часть времени уходит на синхронизацию между ядрами.

На ноутбуке Торвальдса с Intel Core i7-8565U при тестировании в восемь потоков операции со счётчиком ссылок отвечали за 99,92% случаев передачи модифицированных строк кеша между ядрами (HITM).

На проблему ещё в 2024 году обратил внимание разработчик ядра Мэтью Уилкокс (Matthew Wilcox). За прошедшее время предлагалось несколько решений, но у каждого находились недостатки. Сам Торвальдс признался, что около полутора лет использовал собственный экспериментальный вариант, который впоследствии оказался ошибочным.

Как к задаче подключили Claude Code

В октябре Торвальдс опубликовал экспериментальную ветку noref-filemap-read-with-llm с восемью патчами для ядра Linux 7.3-rc6.

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

Позднее появилась переработанная серия из десяти патчей в ветке rcu-free-v3.

Суть решения — убрать операции со счётчиком ссылок из часто используемого пути чтения файлов. Для этого задействовали механизм синхронизации RCU (Read-Copy-Update), который позволяет читать данные без блокировок, откладывая освобождение памяти до завершения уже начатых операций.

Новый флаг PG_rcu_free позволяет отложить освобождение folio, пока его могут использовать читающие потоки. Благодаря этому ядру больше не нужно каждый раз изменять общий счётчик ссылок.

Ускорение в 23 раза. Но есть нюанс

Первые результаты выглядели многообещающе. На ноутбуке Торвальдса производительность при чтении небольших блоков данных в восемь потоков выросла примерно с 10 до 33 млн операций в секунду.

На 64-поточном AMD Ryzen Threadripper переработанная версия показала ещё более заметный прирост:

До изменений — 13,3 млн чтений в секунду.
После изменений — 304 млн чтений в секунду.
Число тактов процессора на одну операцию сократилось примерно с 20 000 до 735.

То есть почти 23-кратное ускорение.

Однако сам Торвальдс предупредил, что цифры получены в синтетическом тесте, где множество потоков многократно читает одни и те же данные. В реальных сценариях прирост будет существенно скромнее.

Кроме того, у оптимизации обнаружились побочные эффекты. В первоначальной версии чтение с дополнительной обработкой ошибок страниц памяти могло замедляться, а отложенное освобождение памяти создавало новые сложности при высокой нагрузке.

На проверке нашли состояние гонки

После публикации патчей к обсуждению подключились другие разработчики ядра.

Мэтью Уилкокс поставил под сомнение отдельные решения по управлению памятью, в том числе использование нового флага PG_rcu_free.

А разработчик Кирилл Шутёмов (Kiryl Shutsemau) обнаружил состояние гонки в функции filemap_read_rcu_batch().

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

Торвальдс предложил изменить порядок проверки размера файла и объединить часть проверок folio. Шутёмов внёс соответствующие изменения.

Разработчики также продолжили обсуждать, как ограничивать объём памяти, ожидающей освобождения через RCU, и что делать с отдельными сценариями чтения, где новая реализация уступает старой.

Что будет с патчами

Торвальдс предложил Кириллу Шутёмову взять на себя дальнейшую работу над серией изменений.

19 октября Шутёмов опубликовал переработанный вариант из 18 патчей. В нём учтена часть замечаний, доработано управление памятью и расширена поддержка чтения без счётчика ссылок.

Новые тесты на ext4, XFS и tmpfs также показали заметный прирост производительности при параллельном чтении небольших блоков данных.

Однако изменения пока находятся на стадии RFC — предложения для обсуждения. В основную ветку ядра они ещё не вошли, а некоторые вопросы реализации остаются открытыми.

В этой истории интересно и само ускорение, и то, как оно было достигнуто. Claude Code помог подготовить решение для проблемы, над которой разработчики ядра работали больше двух лет. Но проверка выявила ошибки, потребовавшие дополнительной работы и пересмотра отдельных решений.

Получился вполне наглядный сценарий применения ИИ в системном программировании: модель помогает писать и исследовать сложный код, а корректность и возможность его включения в ядро по-прежнему определяются тестированием и проверкой со стороны разработчиков.

^{Источники:}^{The New Stack}^,^{обсуждение патчей в списке рассылки ядра Linux}^,^{Phoronix — о переработанной версии}^.

История с патчами Торвальдса показывает, что Claude Code уже способен решать сложные инженерные задачи, хотя без проверки результатов по-прежнему не обойтись. Если хотите попробовать этот инструмент в собственной работе, приходите на бесплатный вебинар Otus, где разберёте, как автоматизировать запуск ИИ-агента и поручать ему задачи по расписанию.