Эксперимент Линуса Торвальдса с генеративным ИИ наглядно очертил границы возможностей современных нейросетей в системном программировании. Применив ассистента Claude Code, создатель Linux сумел сдвинуть с мертвой точки архитектурную проблему, не поддававшуюся разработчикам более двух лет. Результат поразил цифрами в бенчмарках, однако уже через несколько часов человеческий аудит вскрыл скрытую уязвимость, которую созданные искусственным интеллектом тесты попросту проигнорировали.
В чем крылся двухлетний тупик со счетчиком ссылок
Узкое место в страничном кеше ядра (page cache) еще в 2024 году описал разработчик Oracle Мэтью Уилкокс. Проблема давала о себе знать в сценариях, когда десятки потоков одновременно вычитывали крошечные фрагменты одного и того же файла. Ядру приходилось непрерывно обновлять служебный счетчик ссылок структуры folio (блока страниц оперативной памяти), защищая данные от преждевременного удаления.
При высокой конкуренции за один и тот же счетчик ядра процессора начинали буксовать, непрерывно передавая измененную кеш-строку друг другу (события load HITM). В тестах Торвальдса на эту операцию приходилось свыше 99,9% процессорных задержек при многопоточном доступе. Попытки убрать атомарный счетчик ранее проваливались: возникал риск прочитать мусор или столкнуться с ситуацией, когда память освобождается прямо во время трансляции в буфер пользователя.
Идея Торвальдса и реализация руками Claude Code
Решение созрело после осеннего саммита мейнтейнеров в Праге. Линус предложил не проверять корректность задним числом, а исключить саму причину повреждения данных с помощью RCU (Read-Copy Update) — механизма отложенного освобождения страниц. Пока активные операции чтения не завершатся, память гарантированно не будет переназначена другим процессам. Это позволило полностью отказаться от синхронизации счетчика на быстром пути чтения.
Рутинную работу Торвальдс переложил на Claude Code: модель сгенерировала код, написала сопроводительные описания и подготовила набор тестов. Создатель Linux честно зафиксировал авторство в репозитории (ветка noref-filemap-read-with-llm), лично занявшись замерами производительности.
| Конфигурация оборудования | До патча | После оптимизации | Итог |
|---|---|---|---|
| AMD Ryzen Threadripper 3970X (64 потока, btrfs) | 13,3 млн операций/сек (≈20 000 тактов) | 304 млн операций/сек (≈735 тактов) | Ускорение в 23 раза |
| Ноутбук Intel Core i7-8565U (8 потоков, ext4) | ≈10 млн операций/сек (≈2 950 тактов) | ≈33 млн операций/сек (≈725 тактов) | Ускорение в 3,3 раза |
| Intel Core i7-8565U (1 поток, промах буфера памяти) | ≈4 150 тактов | ≈6 550 тактов | Замедление в 1,6 раза |
Показатель в 23 раза Торвальдс сразу призвал воспринимать трезво: это синтетический предельный сценарий, когда все ядра одновременно стучались в один фрагмент. В реальном софте эффект окажется скромнее, а при чтении в еще не выделенные страницы накладные расходы на процессорные исключения даже немного снижают скорость.
Гонка, ускользнувшая от ИИ
Триумф длился недолго. Всего спустя четыре часа после отправки патчей в рассылку LKML разработчик подсистемы памяти Кирилл Шутемов нашел критическую ошибку в функции filemap_read_rcu_batch(). В логике Claude Code таилось незамеченное состояние гонки (race condition).
Суть бага заключалась в следующем: если один поток намеревался прочитать страницу, а второй в этот же микросекундный зазор времени заменял ее в кеше и дописывал файл, первый процесс считывал корректный новый размер файла, но брал данные со старой страницы — получая фантомный «хвост» с мусором. Отложенная очистка RCU спасала от перехвата памяти другим приложением, но не гарантировала ее соответствие текущему содержимому файла.
Автоматические тесты, написанные Claude Code, гонку не выявили: они раз за разом молотили статичный файл, тогда как баг проявляется исключительно при наложении одновременной записи, вытеснения страниц и чтения.
В серверных окружениях и на базах данных подобный сбой мог привести к незаметной порче транзакций, отловить которую на «живой» системе почти невозможно. Потенциальную катастрофу предотвратило лишь то, что Шутемов ранее исследовал этот механизм и прекрасно знал неявные сценарии отказа.
Когда ждать релиз и что это значит для индустрии
Перед уходом в отпуск Линус передал доработку серии Шутемову. Тот оперативно усилил проверки, зафиксировал порядок операций барьерами памяти и вынес спорный флаг PG_rcu_free только на 64-битные архитектуры. В реалистичном тесте со стандартными аппаратными защитами процессора обновленный патч дает около 4,5-кратного ускорения на ext4 для 64 потоков.
В релиз ядра 7.4 изменения не войдут: код все еще носит статус RFC и требует пристального изучения мейнтейнерами. Самое раннее окно появления технологии — релиз Linux 7.5 в 2027 году.
Данный прецедент четко расставил акценты: нейросети отлично справляются с ролью цифрового молотка, быстро собирающего черновики и снимающего психологический барьер со сложных задач. Однако они лишены глубокого контекста периферийных условий и генерируют слепые тесты. Ответственность, поиск неочевидных ловушек и принятие архитектурных решений по-прежнему целиком лежат на инженерах-людях.