Торвальдс и Claude Code ускорили чтение в Linux. Почему этого не хватило для готового патча

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

Мне в этой истории нравится ещё одна деталь. До Claude Code Торвальдс полтора года пользовался собственным ошибочным вариантом решения. В письме он сам об этом рассказал.

Торвальдс занялся чтением небольших фрагментов одного файла сразу многими потоками, то есть параллельно выполняемыми задачами. Проблема возникает в страничном кеше: так называют копии данных файлов в оперативной памяти. Благодаря кешу Linux не приходится всякий раз обращаться к накопителю.

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

В предложенном решении память освобождают с задержкой, чтобы читатель успел закончить работу. Это применение RCU — механизма, который помогает согласовать параллельное чтение и изменение данных. При подходящих условиях читатель обходится без изменения счётчика. Сам подход с отложенным освобождением обсуждали и раньше; приписывать его изобретение Claude Code оснований нет.

В письме от 13 октября Торвальдс объяснил, что решил попробовать решить давнюю проблему с помощью ИИ к саммиту разработчиков ядра. Точного запроса к Claude Code в публикации нет.

Ускорение примерно в 23 раза Торвальдс получил на Ryzen Threadripper в специальном тесте с 64 потоками. Они снова и снова читали один маленький участок страницы памяти. Число чтений выросло с 13,3 млн до 304 млн в секунду. Это результат переработанной серии патчей — изменений кода — в ветке rcu-free-v3.

В той же таблице Торвальдса затраты ядра на одно чтение упали примерно с 20 000 до 735 тактов процессора. Получившееся ускорение относится к повторному чтению в таких условиях. Ни FPS в играх, ни скорость запуска программ здесь не измеряли.

Торвальдс тут же предупредил: тест очень искусственный, реальный эффект будет гораздо меньше. Ни одна реальная нагрузка не увидит эту цифру — таков смысл его отдельной оговорки в конце письма. Я считаю, что без неё новость про 23 раза теряет главное условие.

Цифра около 10 млн → 33 млн чтений в секунду взята из более ранней версии. Её Торвальдс тестировал на ноутбуке Intel Core i7-8565U: восемь потоков читали по 16 байт из начала одного файла в файловой системе ext4. Защиты процессора от уязвимостей и дополнительная проверка копирования памяти были выключены. Это другой компьютер и другая версия кода.

Причём сам Торвальдс советовал сравнивать затраты на чтение: ноутбук менял частоту из-за нагрева, и число чтений в секунду плавало. Смешивать оба замера в один рассказ об ускорении всего Linux нельзя.

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

Шутёмов предложил ещё раз проверить, что блок остаётся в кеше, после получения размера файла. Торвальдс предложил переставить проверку размера и объединить проверки блока. На следующий день Шутёмов прислал исправленный вариант. Здесь уже можно назвать конкретные действия людей, которые изменили решение после его публикации.

Обсуждение касалось и цены оптимизации. Задержанное освобождение означает, что часть памяти ещё нельзя использовать заново. Разработчик Педро Фалкато возразил: менять систему управления памятью ради такого выигрыша стоит, когда найдётся существенно ускорившийся реальный сценарий. Одного маленького искусственного теста ему было недостаточно.

Claude Code помог с кодом, тестовыми программами, предварительным разбором проблем и первым черновиком описания — именно такой список привёл Торвальдс. Работу вели под его руководством, измерения он выполнил на своей машине. Процент машинного кода или сэкономленных часов он не назвал. Кто сделал основную работу, по этим сведениям не посчитать.

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

На Хабре вторичный пересказ вышел с заголовком о коде, который не прошёл проверку. Но сам текст сообщает о дальнейшей доработке. Phoronix тоже описал продолжение работы, а LWN после обнаружения гонки написал о необходимости исправлений. Письмо Шутёмова от 19 октября имеет статус RFC, предложения для обсуждения. Окончательного отказа в этой переписке нет.

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

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

После результата Claude Code появились замечания разработчиков и новая серия изменений. В письме с этой серией Шутёмов по-прежнему просил проверить открытые вопросы.