На всех машинах была установлена система с ядром Linux 4.19-rc1, выпущенным в минувшие выходные. На Intel соответствующие патчи включают изоляцию таблиц страниц (PTI/KPTI) для Meltdown и различные патчи Spectre против спекулятивного исполнения команд, в том числе очистку указателя __user, использование retpoline через IBPB IBRS_FW, патч для уязвимости Speculative Store Bypass с помощью prctl и seccomp, а также инверсию PTE и сброс условного кэша в виртуальных машинах — это для L1TF/Foreshadow.
По умолчанию ядро Linux не обеспечивает «полную» защиту от уязвимостей путём отключения поддержки Intel HT/SMT, поэтому имейте это в виду, если используете виртуальные машины и предоставляете ненадёжному коду или пользователям доступ к VM. Если выбрать полную защиту и отключить SMT, то влияние на производительность намного заметнее из-за сокращения вдвое числа доступных потоков. Провайдеры облачных сервисов, похоже, просто настраивают планировщики, чтобы потоки SMT не проходили через пользователей. Это позволяет избежать очевидных огромных затрат на отключение Hyper Threading. Так что сейчас мы сравниваем только защиту стокового/дефолтного ядра.
На AMD EPYC по умолчанию реализована защита только для соответствующих уязвимостей, которые их касаются: это очистка указателя __user для Spectre V1, AMD Retpoline IBPB для Spectre V2 и отключение Speculative Store Bypass (SSBD) для Spectre V4.
После тестирования всех конфигураций на стоковом ядре Linux 4.19-rc1 тесты повторили с применением различных переключателей защиты в рантайме. Все системы тестировались с Ubuntu 18.04.1 LTS x86_64 с ядром Linux 4.19-rc1 через Ubuntu Mainline Kernel PPA, последними микрокодами/BIOS, GCC 7.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.
Для статьи выбраны тесты, которые имеют отношение к Spectre/Meltdown, то есть с интенсивным вводом-выводом или взаимодействиями ядра. Нагрузка идёт просто на CPU и не сильно зависит от процессорного кэша.
Профиль CompileBench — вероятно, самый простой способ показать влияние Spectre/Meltdown. На ядре Linux 4.19 при активации защиты процессоры Intel демонстрируют снижение производительности на 7?16%., а процессоры AMD — на 3?4%.
Похожая ситуация в подтестах с чтением скомпилированного дерева. У процессоров Intel снижение производительности на 14?15%, у AMD — на 4?5%.
В реальных задачах вроде компиляции ядра Linux разница в производительности будет в районе 2%.
Бенчмарк планировщика ядра Hackbench тоже страдает от активации защиты. В процессорах Intel производительность снижается примерно на 20%, кроме Xeon Gold. В системах AMD EPYC особой разницы нет.
Сервер баз данных PostgreSQL — одно из реальных приложений, которое пострадало от снижения производительности после установки защиты на процессоры. В этом конкретном тесте разница для процессоров Intel составила 5?8%, а у EPYC — 1%.
Ещё одна реальная программа со снижением производительности из-за Spectre/Meltdown — графический редактор GIMP. Разница для Intel составляет 5?10%, для AMD — 0?2%.
СУБД Redis на системе Intel Skylake E3 v5 замедляется на 11%, а на других процессорах Intel — на 5?7%, у систем AMD EPYC разница составляет 1?5%.
Веб-сервер Nginx на протестированных системах Xeon на ядре Linux 4.19 показал разницу в производительности до 20%, а на AMD EPYC — от 1?2% до 6%.
Аналогично и веб-сервер Apache при дефолтной установке работает значительно медленнее после активации защиты на процессорах Intel и практически без изменений на процессорах AMD.
В тесте на скорость создания файлов OSBench система на Intel Xeon замедляется на 13?16%, а системы EPYC — на 6?9%.
В тесте на создание потоков тоже видна ощутимая разница между процессорами Intel и AMD.
При запуске программ и создании процессов есть меньшая, но заметная разница в работе ядра Linux 4.19 по умолчанию по сравнению с отключенной защитой.
Вот так обстоят дела с производительностью процессоров на ядре Linux 4.19 после установки патчей. Имейте в виду, если ваша система (системы) открыта для ненадёжных пользователей/кода, особенно в виртуальных машинах, то для защиты могут потребоваться дополнительные действия, такие как l1tf=full, вплоть до отключения SMT/HT или обязательного сброса кэша L1, что ещё больше снизит производительность систем. О влиянии этих защит от L1TF/Foreshadow более подробно рассказано в прошлой статье.
Возможно, в будущем мы проведём похожие тесты на Linux 4.19 с десктопными процессорами и соответствующими рабочими нагрузками.
Комментарии (55)
safari2012
31.08.2018 15:37Подскажите, есть ли уже модели/ревизии десктопных процессоров Core i7, где эти уязвимости пофикшены без потери производительности? А то назрел апгрейд домашнего компа. Уже полгода жду…
rt3879439
31.08.2018 15:40Нет таких.
safari2012
31.08.2018 15:47даже в роадмапах?
lokkiuni
31.08.2018 17:16Есть, но когда будет, не известно (много проблем с техпроцессом, уже должны были 10нм освоить — фактически ещё не получается), и по обещаниям, наконец-то новая архитектура (текущая по факту 10 лет капитально не перетряхивалась и лет 5 — вообще никаких изменений, новую делает автор феномов и рейзнов). Можно только АМД предложить, 2700х весьма и весьма хороши, в многопоточке быстрее, чем десктопные и7, в однопотоке — примерно такие же (зависит, в частности, от памяти — на АМД очень большой прирост от оной). Большей части уязвимости в них нет (поэтому и пенальти сильно меньше) — Epyc это фактически 4 кристалла рейзна 1800х на одной подложке, соединённые шиной, 4-процессорная система в одном сокете и 8-процессорная — в двух.
springimport
31.08.2018 19:03Сколько не видел тестов, 2700x проигрывает даже i5-8400. Как может быть быстрее 4ггц ядро ядра 5 ггц. Причем проигрывает до 20%.
aPiks
31.08.2018 19:53Вы верно шутите, потому что Ryzen 7 второй генерации, почти не отстает от i7 8700K, спокойно обгоняя i5.Правда и стоит он теперь как i7.
springimport
31.08.2018 20:01Не шучу. Легко это понять тестируя игры. Первый попавшийся обзор.
Во всех играх (с небольшими исключенями) ryzen загружен на 20-30% и выдает условные 100 fps, в то время как 8700k загружен на 40-60%, выдавая 120-130 кадров.
Мало того, для ryzen нужна очень хорошая память.
Повторюсь, речь идет про производительность на ядро. И по моему мнению, это более важнее чем общая производительность. Мне нравится как в обзорах постоянно записывают в плюсы большие возможности рендеринга и самое главное — говорят так будто каждый второй включает компьютер и сразу запускает какой-то рендер.
По факту, даже если ядро интела медлнее ядра амд, интел решает за счет частоты и это факт. А апеллировать к малому количеству ядер у интела уже нельзя потому что 6 ядер.Jamdaze
31.08.2018 20:10144Гц монитор тоже далеко не у каждого второго.
springimport
31.08.2018 20:25+1У меня 165, например. Но что это меняет?
Объясняю.
1. Количество кадров снижается на всех разрешениях. В абсолютном количестве на малых разрешениях — сильнее. Вполне может быть что вместо комфортных 60 получится 55.
2. Мне показалось что вы думаете что 120 кадров на 60гц мониторе не надо? Нет, как раз надо и очень даже: больший запас можно оставить на v-sync (садит минимум на 10%) или fast-sync (вообще требует раза в два больше кадров, такая концепция); из-за видимой разницы в следствии неодинаковой скорости отрисовки кадра (буквально при 60 кадрах задержка в пол кадра будет очень видна, при 120 — нет).
Надеюсь, расписал понятно.iga2iga
01.09.2018 00:54+1Зачем рисовать больше кадров, чтобы часть из них «оставить на v-sync»??? Когда вместо рисования можно просто «поспать» ровно столько же времени сколько рисуется еще один кадр… Я тут чуть ладонью лоб не пробил… v-sync он на то и существует, чтобы рисовать столько же кадров, сколько умеет показывать отображающее устройство, читай монитор.
ZimM
01.09.2018 12:37Вы ведь не серьезно, правда? V-sync значительно увеличивает задержку ввода. Геймеры часто готовы получить картинку с разрывами в обмен на более быструю реакцию. Я никогда и нигде, кроме каких-нибудь карточных игр, не включаю vsync именно по этой причине — управление начинает «плыть».
iga2iga
01.09.2018 16:49Потрудитесь объяснить с технической точки зрения каким образом «v-sync значительно увеличивает задержку ввода». Ну то есть имеется некая sleep(10ms) после рисования очередного кадра, во время которой по прежнему обрабатывается ввод и вывод и вообще всё что можно, но только не рисуется картинка. Каким образом sleep влияет на задержку ввода?
ZimM
01.09.2018 17:19Игра получила ввод. Нарисовала с учетом этого ввода кадр. Ждет всинка 10 мс. Итог — юзер видит результат своего ввода на 10 мс позже. Ввод может обрабатываться в эти 10 мс сколько угодно, но юзер этого не почувствует никак вплоть до следующего кадра. Если видеокарта выдает 250фпс на 60 Гц мониторе, то в момент, когда монитор начнет отрисовывать последний кадр, этот кадр будет содержать гораздо более актуальный ввод, нежели при случае с 60 фпс при 60 Гц мониторе.
ZimM
01.09.2018 17:23Иными словами, при 60Гц мониторе, с включенным всинком вы получаете переменную 0-16мс задержку ввода (в зависимости от того, когда кадр был нарисован относительно синхронизации монитора). В то же время, при стабильных 250 FPS на 60 Гц мониторе вы получаете задержку в стабильные 4 мс.
iga2iga
01.09.2018 20:43Хорошо, у нас есть заранее неправильно спроектированная игра с SDL-like вводом, это когда основной цикл игры выглядит так:
1. информация о вводе
2. отрисовка кадра и sleep
3. goto 1
При всем при этом отрисовка кадра игры синхронизируется не по sleep а по неким внутренним счетчикам, ну то есть на сколько градусов надо повернуть скажем башню, за кадр (важно). При этом каждый кадр с синхронизацией остается актуальный для каждого ввода.
Теперь тоже самое без синхронизации, имеется внутренний счетчик времени, кадров рисуется до одурения много и опросов ввода так же много, но актуальных кадров (которые мы видим на мониторе) ровно столько же, кажем 60, т.к. монитор больше не умеет, и угол поворота башни будет ровно таким же как без синхронизации. Просто в одном случае мы спали, в другом были заняты рисованием «невидимого кадра» от «ненужного» ввода. Так и в чем разница? Ну вводов больше, кадров больше, актуальных кадров и актуальных вводов ровно столько же.iga2iga
01.09.2018 20:59Грубо говоря, если игра выдает 240 кадров и 240 раз в секунду опрашивает клавиатуру/мышь. То на экране то мы видим только 60 из этих кадров, это 1 из 4х кадров и 1 из 4х опросов устройств ввода, притом, что этот кадр абсолютно такой же как и кадр нарисованный с синхронизацией. И башня повернута на столько же градусов. Ну я не спорю могут быть какие-то погрешности, но не такие о которых вы говорите. Сам монитор так же может давать значительную задержку при отрисовке им кадра, как и видеокарта на выходе, но это уже железный вопрос, а не софтовый. И ВК не будет пихать в монитор 240 кадров, это будут все те же 60 кадров. Ни стандартные HDMI ни DP не способны передавать 240 кадров/сек, ни FHD, ни особенно 4k.
ZimM
01.09.2018 21:45> Грубо говоря, если игра выдает 240 кадров и 240 раз в секунду опрашивает клавиатуру/мышь. То на экране то мы видим только 60 из этих кадров, это 1 из 4х кадров и 1 из 4х опросов устройств ввода
Совершенно верно. Экран не нарисует в итоге больше 60 кадров, так что 180 кадров и 180 опросов ввода пропадут впустую. Я с этим не спорил. Я говорю, что без всинка тот ввод, результат которого все-таки «попадет» на экран, будет более актуален.
Давайте рассмотрим ситуацию с всинком (60 фпс) и без (240 фпс) на 60 Гц мониторе. За t=0 возьмем время момент отрисовки последнего кадра.
t=-4ms
Всинк — юзер двинул мышкой вверх, обновили ввод,
нарисовали кадр с учетом того, где камера при таком вводе должна оказаться через 16 мс.
Без всинка — юзер двинул мышкой вверх, обновили ввод, нарисовали кадр с учетом того, где камера при таком вводе должна оказаться через 4 мс.
t=0ms
Всинк — монитор вывел кадр. Ждем 16 мс…
Без всинка — монитор вывел кадр.
t=4ms
Без всинка — обновили ввод, ничего не изменилось, нарисовали кадр.
t=8ms
Без всинка — обновили ввод, ничего не изменилось, нарисовали кадр.
t=12ms
Без всинка — юзер дернул влево, обновили ввод, отрисовали кадр с учетом поворота влево.
t=16мс
Всинк — на экран выведен кадр с учетом только ввода вверх, ввод влево никак не отражен.
Без всинка — на экран выведен кадр с учетом ввода за последние 12 мс, и вверх, и влево.
Неважно, сколько кадров/сек передает монитор, ввод на момент вывода картинки будет более актуален, если игра рисует больше кадров. Но конечно, еще лучше, если монитор способен физически выводить 120+ Гц.
И я не понимаю, почему вы так яростно теоретизируете — это не гипотетическая проблема, которую нельзя пощупать, достаточно включить в любой игре всинк. Не будете ведь убеждать, что это эффект по типу плацебо?ZimM
01.09.2018 21:52> Экран не нарисует в итоге больше 60 кадров, так что 180 кадров и 180 опросов ввода пропадут впустую.
Уточнение, только 180 кадров пропадут, так как не будут выведены на экран. Ввод не пропадет.
zartarn
31.08.2018 20:41+1Выше уже сказали же, что еще от памяти зависит. И что мы видим в тесте?
у i7 память 2х8 Patriot Viper 4 PV416G373C7K @ 3733 МГц (XMP)
а у ряженки 2х16 G.Skill Trident Z @3200 МГц (14-14-14-14-28)
Во всех играх (с небольшими исключенями) ryzen загружен на 20-30% и выдает условные 100 fps, в то время как 8700k загружен на 40-60%, выдавая 120-130 кадров.
А это в потоки упирается. т.е. исопльзуется одинаковое количество, а загруженность разная, так как ряженка умеет больше.
Вот есть наглядный тест правда i5/2600x, для меня там разница в районе погрешности, и разница больше от движка зависит (может оптимизации какие компилятором под процы?).
Ну и везду форсируемый «плюс» воткну: у амд сокеты реже меняются, а так же под крышкой не термопаста.
Ни к чему не призываю, выводы каждому свои :)
Заголовок спойлераspringimport
31.08.2018 20:52Не обратил внимание на память, да. Как правило, сколько не видел тестов — везде одинаковая ситуация.
И вот вы приводите пример с 8600k с 2700x. Тестируется более слабая модель с самой сильной, но мало того, еще и со вторым поколением.
Я не к тому что кто-то однозначно круче кого-то. Важна объективность. У интела нет припоя, сокеты слишком часто меняются. У амд процессоры почти всегда слабее в однопотоке и сильнее в многопотоке.
Для себя все же выбрал интел — мне очень важна скорость одного ядра. А что до многоядерности — не стримлю и не рендерю — мне хватило бы и 4 ядер, 2 дополнительных скорее приятная добавка.
Еще хочу заметить что по прикидкам в комментах на профильных ресурсах, амд получаются если не дороже, то и не дешевле сборки с интелом. Все из-за недешевых новых процессоров и очень дорогой памяти.Solexid
31.08.2018 20:552600x там, а не 2700х. Так что после второго абзаца можно было ничего и не писать.
springimport
31.08.2018 21:05
Cast_iron
31.08.2018 22:25Для десктопных процессоров материнки для LGA 1151 намного дороже, чем AM4 в сравнимых категориях. (по крайней мере весной так было)
dartraiden
01.09.2018 00:50+1И что мы видим в тесте?
От памяти в играх сильно зависит только Ryzen, если мне не изменяет память. Потому что у него на частоту памяти завязана шина, по которой общаются ядра между собой и с периферией. C Intel выигрыш будет ощутим в тестах и специализированных задачах, потому что частота памяти кроме самой памяти ни на что не влияет.
mistergrim
01.09.2018 06:34> Легко это понять тестируя игры.
Вот чёрт, а я не тестирую игры (и даже не играю в них).
Fracta1L
01.09.2018 08:55Если вы на компьютере только и делаете, что в игрульки шпилите, то проблема уязвимостей в процах для вас вообще не актуальна, и зачем вы тут всё это пишите — непонятно.
zartarn
31.08.2018 20:50Правда? А я вот вижу что i7-8700k стоит 33 790, а Ryzen 2700x стоит 23990 (и это не CU).
springimport
31.08.2018 20:58Я не знаю цен в рублях. Да и не объективно это. На амазоне первый стоит 360 (но я покупал месяц назад за 350), второй стоит 320. Разница примерно 30 долларов.
Выше я отметил что амд требует очень хорошую (=дорогую) память.
То на то и выходит.zartarn
31.08.2018 21:00На CU цены сейчас такого порядка:
i7-8700k — 321,84 € 25 643 руб.
Ryzen 2700x — 274,78 € 21 893 руб.
В России цены с НДС, выше привел.
0xd34df00d
31.08.2018 21:09На avx вроде отстает, да и аналога mkl там нет.
Kobalt_x
01.09.2018 08:13MKL прекрасно работает и на amd
0xd34df00d
01.09.2018 18:07Насколько прекрасно?
По моему опыту разница в производительности до и после подключения MKL может составлять примерно порядок, на интелах, конечно.
dartraiden
01.09.2018 00:48А откуда 5 ГГц? 8400 даже в турбо-бусте такой частоты не достигает (там предел — 4 ГГц и то, если нагружено одно ядро, что практически недостижимо в реальной жизни), а у 2700x потолок разгона тоже где-то в районе 4 ГГц.
interprise
31.08.2018 15:43Веб-сервер Nginx на протестированных системах Xeon на ядре Linux 4.19 показал разницу в производительности до 20%. Так то это совсем не кисло, 20%
achekalin
31.08.2018 17:35Крайне любопытно и обратное: если машина у меня физическая, и она строго «моя» (а выжать скорости хочется побольше), там никого, кроме меня, нет, то — что можно и будет разумным отключить, чтобы скорость падала не сильно?
Kobalt_x
31.08.2018 17:49Да, конечно, всякие кластеры и прочие HPC/HPE не будут патчить все узлы чтобы разом потерять 7-16 % а с нарушителями там проще бороться административными мерами.
achekalin
31.08.2018 17:52Да и стоящий под столом «серверок для меня одного» особого смысла не имеет патчить — поэтому вопрос лично для меня очень интересен.
Тем более что проблем нашли довольно много, и не все уже следят за ними пристально, зато обновления к ОС регулярно привносят в работу сервера ту или иную «мелочь» в смысле защиты — порой, как в описанном случае, даже и не нужной.
Так вы не знаете ответа?Kobalt_x
31.08.2018 17:59ну насколько мне известно для meltdown/spectre нужен запуск на железе своего кода т.е. либо rce либо malicuous скрипты в браузере(вроде было демо что можно триггернуть из js) для foreshadow насколько я понял тоже, причем ещё и чтобы атакуемое приложение было на smt сестринском треде физического ядра, что тоже означает что нужна rce
rt3879439
31.08.2018 17:53Если у вас не выполняется чужой код, которому вы не доверяете вроде javascript с сайтов, то можете не патчиться.
achekalin
31.08.2018 17:56Так я не против не патчиться, но apt upgrade делать выборочно — это самому себе проблемы создавать. А про возможность общесистемно сказать «мне защиты от дыр в процах не надо» я как-то не знаю…
0xd34df00d
31.08.2018 21:11Я в ядре все защиты выключил, убедился, что retpoline при сборке не используется, и не буду обновлять микрокод.
Джаваскрипт в браузерах вроде как давно починен огрублением таймеров. Да и скорости там смешные, порядка байт в секунду.
Harbour
01.09.2018 13:23а на десктопе может все будет еще печальней — топовые процы ведь самые быстрые…
lev_sibov
01.09.2018 13:33Интересно бы было увидеть как коррелирует потеря производительности с количеством системных вызовов, прерываний и переключений контекста для каждой конкретной бенчмарки.
rt3879439
Хотелось бы видеть более серьезный тест IO, желательно на жирной базе, с использованием SSD или довольно быстрой дисковой полки.