Главное
- При восьми потоках скорость выросла с 9,9-10,4 млн до 30-33 млн чтений в секунду.
- Claude Code подготовил код, тестовые программы, разбор известных проблем и первый черновик описания.
- Патчи пока не включены в основное ядро Linux и не прошли полный набор проверок.
Как нейросеть изменила работу с памятью
Торвальдс руководил работой Claude Code и проводил измерения на своем компьютере. Изменения затрагивают страничный кэш, хранилище недавно прочитанных файлов в оперативной памяти.
Проблема возникала при одновременном чтении небольших частей одного файла несколькими потоками. Ядро учитывает каждое обращение к странице памяти с помощью счетчика.
При одновременной работе процессорных ядер изменения этого счетчика приходится постоянно согласовывать. В тесте с восемью потоками на это пришлось 99,92% зарегистрированных событий передачи измененных данных между ядрами. Показатель отражает число таких событий, а не долю времени работы программы.
Патчи позволяют читать данные без постоянного изменения счетчика. Для этого применяется RCU, механизм отложенного повторного использования памяти.
Если страницу удалили из файлового кэша, ее память временно не используется для других данных. Ограничение действует, пока защищенное чтение не завершится.
Что показали испытания
В тесте с восемью потоками скорость выросла примерно втрое. Она поднялась с 9,9-10,4 млн до 30-33 млн чтений в секунду.
Четыре потока на отдельных физических ядрах выполняли 25-26 млн операций вместо 8,9-11,6 млн. Один поток ускорился с 7,9-8,1 млн до 8,8-8,9 млн операций.
При восьми потоках затраты на одну операцию сократились примерно с 2950 до 725 процессорных циклов. Число событий передачи измененных данных между ядрами снизилось с 30 538 до 101.
Все результаты получены на одном ноутбуке с процессором Intel Core i7-8565U. У него четыре физических ядра и восемь потоков. Тесты использовали файловую систему ext4, а часть защитных механизмов ядра была отключена.
Торвальдс допустил более заметный результат на многопроцессорных серверах, но такие испытания не проводил.
Какие проблемы остались
Отложенное освобождение страниц может увеличить расход оперативной памяти. Риск особенно заметен, когда программы часто создают и удаляют данные.
В раннем испытании компьютер с 2 ГБ памяти преждевременно запустил OOM Killer. Этот механизм принудительно завершает процессы при нехватке памяти. Дополнительные изменения помогли пройти тест, но полностью проблему не устранили.
Отдельный сценарий чтения замедлился. Если нужных данных нет в оперативной памяти, новый алгоритм сначала безуспешно пытается их скопировать.
После этого система возвращается к прежнему способу. В таком тесте затраты выросли примерно с 4100 до 6500 процессорных циклов.
Остаются вопросы с выделением непрерывных областей памяти и архитектурой s390. Также неизвестны затраты на массовое освобождение страниц при длительной нагрузке.
Патчи не проверялись стандартным набором файловых тестов и средством поиска ошибок доступа к памяти. Испытаний 32-битных сборок, других компьютеров и некоторых конфигураций ядра также не было.
Экспериментальная серия находится в отдельной ветке на основе Linux 7.3-rc6. Сроки возможного включения в основное ядро неизвестны. Торвальдс признал, что «не уверен в правильности некоторых архитектурных решений».
Подробности: SecurityLab
