Хабрахабр

[Перевод] Влияние защиты от Spectre, Meltdown и Foreshadow на производительность Linux 4.19

Один из самых частых вопросов в последнее время — как отражается на производительности Linux защита от Meltdown/Spectre, а теперь ещё и от L1TF/Foreshadow. Начало разработки ядра Linux 4.19 в этом месяце подлило масла в огонь не только для x86_64, но и для POWER/s390/ARM. Чтобы получить общее представление о влиянии патчей на производительность, я протестировал три системы Intel Xeon и две системы AMD EPYC, а также виртуальную машину с каждой стороны, чтобы оценить производительность ядра Linux 4.19 по умолчанию с соответствующими патчами и без них.

19-rc1, выпущенным в минувшие выходные.
На всех машинах была установлена система с ядром Linux 4. На Intel соответствующие патчи включают изоляцию таблиц страниц (PTI/KPTI) для Meltdown и различные патчи Spectre против спекулятивного исполнения команд, в том числе очистку указателя __user, использование retpoline через IBPB IBRS_FW, патч для уязвимости Speculative Store Bypass с помощью prctl и seccomp, а также инверсию PTE и сброс условного кэша в виртуальных машинах — это для L1TF/Foreshadow.

Если выбрать полную защиту и отключить SMT, то влияние на производительность намного заметнее из-за сокращения вдвое числа доступных потоков. По умолчанию ядро Linux не обеспечивает «полную» защиту от уязвимостей путём отключения поддержки Intel HT/SMT, поэтому имейте это в виду, если используете виртуальные машины и предоставляете ненадёжному коду или пользователям доступ к VM. Это позволяет избежать очевидных огромных затрат на отключение Hyper Threading. Провайдеры облачных сервисов, похоже, просто настраивают планировщики, чтобы потоки SMT не проходили через пользователей. Так что сейчас мы сравниваем только защиту стокового/дефолтного ядра.

На AMD EPYC по умолчанию реализована защита только для соответствующих уязвимостей, которые их касаются: это очистка указателя __user для Spectre V1, AMD Retpoline IBPB для Spectre V2 и отключение Speculative Store Bypass (SSBD) для Spectre V4.

19-rc1 тесты повторили с применением различных переключателей защиты в рантайме. После тестирования всех конфигураций на стоковом ядре Linux 4. 04. Все системы тестировались с Ubuntu 18. 19-rc1 через Ubuntu Mainline Kernel PPA, последними микрокодами/BIOS, GCC 7. 1 LTS x86_64 с ядром Linux 4. 3 и файловой системой EXT4.

Конфигурации систем в тесте:

  • Intel Xeon E3-1280 v5 Skylake на материнской плате MSI Z170A SLI PLUS, 16 ГБ DDR4 и 256 ГБ Toshiba RD400 NVMe SSD.
  • Intel Xeon E5-2687W v3 Haswell на материнской плате MSI X299 SLI PLUS, 32 ГБ DDR4 и 80 ГБ Intel 530 SATA 3.0 SSD.
  • Два Intel Xeon Gold 6138 в стойке Tyan 1U с 96 ГБ RAM и Samsung 970 EVO NVMe SSD 256 ГБ.
  • Виртуальная машина KVM на вышеупомянутом двухпроцессорном сервере Xeon Gold. Эта VM являлась единственным активным процессом на машине и была сконфигурирована на доступ к 80% ядер/потоков CPU (64 потока), 48 ГБ RAM и виртуальному диску 118 ГБ. Во время тестирования защита от уязвимостей отключалась и на хосте, и в VM.
  • AMD EPYC 7601 на сервере Tyan 2U со 128 ГБ RAM и 280 ГБ Intel Optane 900p NVMe SSD.
  • Виртуальная машина KVM на вышеупомянутом сервере AMD EPYC 7601. У неё доступ к 80% ядер/потоков CPU (52 потока), 48 ГБ RAM и виртуальному диску 120 ГБ.
  • Сервер AMD EPYC 7551 на материнской плате Gigabyte MZ31-AR0 с 32 ГБ RAM и Samsung 960 EVO 256GB NVMe SSD.

Очевидно, конфигурации машин разные и они не предназначены для сравнения друг с другом, а именно для проверки включения/отключения защиты от уязвимостей процессоров на ядре Linux 4.19. Поэтому для наглядности все данные нормализованы по производительности каждой системы. Все тесты из набора Phoronix Test Suite.

Нагрузка идёт просто на CPU и не сильно зависит от процессорного кэша. Для статьи выбраны тесты, которые имеют отношение к Spectre/Meltdown, то есть с интенсивным вводом-выводом или взаимодействиями ядра.

На ядре Linux 4. Профиль CompileBench — вероятно, самый простой способ показать влияние Spectre/Meltdown. 19 при активации защиты процессоры Intel демонстрируют снижение производительности на 7−16%., а процессоры AMD — на 3−4%.

У процессоров Intel снижение производительности на 14−15%, у AMD — на 4−5%. Похожая ситуация в подтестах с чтением скомпилированного дерева.

В реальных задачах вроде компиляции ядра Linux разница в производительности будет в районе 2%.

В процессорах Intel производительность снижается примерно на 20%, кроме Xeon Gold. Бенчмарк планировщика ядра Hackbench тоже страдает от активации защиты. В системах AMD EPYC особой разницы нет.

В этом конкретном тесте разница для процессоров Intel составила 5−8%, а у EPYC — 1%. Сервер баз данных PostgreSQL — одно из реальных приложений, которое пострадало от снижения производительности после установки защиты на процессоры.

Разница для Intel составляет 5−10%, для AMD — 0−2%. Ещё одна реальная программа со снижением производительности из-за Spectre/Meltdown — графический редактор GIMP.

СУБД Redis на системе Intel Skylake E3 v5 замедляется на 11%, а на других процессорах Intel — на 5−7%, у систем AMD EPYC разница составляет 1−5%.

19 показал разницу в производительности до 20%, а на AMD EPYC — от 1−2% до 6%. Веб-сервер Nginx на протестированных системах Xeon на ядре Linux 4.

Аналогично и веб-сервер Apache при дефолтной установке работает значительно медленнее после активации защиты на процессорах Intel и практически без изменений на процессорах AMD.

В тесте на скорость создания файлов OSBench система на Intel Xeon замедляется на 13−16%, а системы EPYC — на 6−9%.

В тесте на создание потоков тоже видна ощутимая разница между процессорами Intel и AMD.

19 по умолчанию по сравнению с отключенной защитой. При запуске программ и создании процессов есть меньшая, но заметная в работе ядра Linux 4.

19 после установки патчей. Вот так обстоят дела с производительностью процессоров на ядре Linux 4. О влиянии этих защит от L1TF/Foreshadow более подробно рассказано в прошлой статье. Имейте в виду, если ваша система (системы) открыта для ненадёжных пользователей/кода, особенно в виртуальных машинах, то для защиты могут потребоваться дополнительные действия, такие как l1tf=full, вплоть до отключения SMT/HT или обязательного сброса кэша L1, что ещё больше снизит производительность систем.

19 с десктопными процессорами и соответствующими рабочими нагрузками. Возможно, в будущем мы проведём похожие тесты на Linux 4.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть