Механизм защиты от Spectre замедляет работу Linux в 1,6 раза

Механизмы защиты от уязвимостей класса Spectre в центральных процессорах снижает производительность компьютеров под управлением Linux, и некоторые пользователи отключают ее ради более высокой скорости.

Бывший инженер Mozilla Роберт О’Каллахан (Robert O'Callahan), который в настоящее время занимается разработкой инструмента для отладки Pernosco, недавно работал над инструментом для отладки с открытым исходным кодом rr debugger (расширяемый Pernosco) и обнаружил, что частые системные вызовы замедляют выполнение кода в пространстве пользователя, где запускаются приложения.

Предположив, что частично это связано с различными механизмами защиты от Spectre, О’Каллахан отключил их и перезапустил свое тестирование команды rr sources, предназначенной для кэширования результатов многих системных вызовов доступа, проверяющих наличие каталога. Результаты оказались неутешительными.

«Выходит, защита от Spectre замедляет предварительную оптимизацию пространства пользователя в два раза (думаю, из-за кэша и сброса TLB-буферов), и вся рабочая нагрузка замедляется в 1,6 раза! До реализации защиты от Spectre эти системные вызовы почти совсем не замедляли выполнение в пространстве пользователя», - сообщил О’Каллахан.

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

Опубликованные Phoronix результаты тестов демонстрируют замедление от 2% до 16% на чипах Intel Rocket Lake (микропроцессорах Core 11-го поколения) при включенных средствах защиты от Spectre. Другие тесты показывают замедление в диапазоне 10-30%. Тем не менее, в AWS не зафиксировали значительного влияния на производительность для подавляющего большинства рабочих нагрузок EC2.

Как пояснил О’Каллахан, общее замедление составило всего 1,6 раза. Работа с пользовательским пространством замедлилась в 2 раза, но это произошло только потому, что его команда в своей работе делает частые системные вызовы, и эти системные вызовы потребляют большую часть времени в этом тесте.

«Я ожидаю, что эти результаты будут верны и для других рабочих нагрузок, которые так же требуют большого количества системных вызовов», - отметил инженер.