Будет ли замедлено выполнение gettimeofday() из-за исправления недавно объявленной ошибки Intel?
Я оценивал влияние недавно объявленной ошибки Intel на мое приложение для обработки пакетов, используя netmap. До сих пор я измерял, что я обрабатываю около 50 пакетов на каждый poll() системный вызов сделан, но эта цифра не включает gettimeofday() звонки. Я также измерил, что я могу читать из несуществующего дескриптора файла (что является самой дешевой вещью, которую может сделать системный вызов) 16,5 миллиона раз в секунду. Моя скорость обработки пакетов составляет 1,76 миллиона пакетов в секунду, или, с точки зрения системных вызовов, 0,0352 миллиона системных вызовов в секунду. Это означает, что снижение производительности составило бы 0,0352 / 16,5 = 0,21333%, если штраф за системный вызов удвоится, вряд ли о чем я должен беспокоиться.
Тем не менее, мое приложение может использовать gettimeofday() системные вызовы довольно часто. Насколько я понимаю, это не настоящие системные вызовы, а реализованные как виртуальные системные вызовы, как описано в разделе Что такое vdso и vsyscall?,
Теперь мой вопрос: замедляется ли исправление недавно объявленной ошибки Intel (которая может повлиять и на ARM и, вероятно, не повлияет на AMD)? gettimeofday() системные вызовы? Или gettimeofday() совершенно другое животное из-за того, что оно реализовано как виртуальный системный вызов другого типа?
2 ответа
В общем нет.
Текущие исправления хранят такие вещи, как страницы vDSO, отображаемые в пользовательском пространстве, и изменяют поведение только для оставшегося подавляющего большинства страниц, предназначенных только для ядра, которые больше не будут отображаться в пользовательском пространстве.
На большинстве архитектур gettimeofday() реализован как чисто пользовательский вызов и никогда не входит в ядро, не включает сброс TLB или переключатель CR3, что подразумевает KPTI, поэтому вы не должны видеть влияния на производительность.
Исключения включают необычные конфигурации ядра или оборудования, которые не используют механизмы vDSO, например, если у вас нет постоянной rdtsc или если вы явно отключили rdtsc хронометраж через параметр загрузки. Вы, наверное, уже знаете, если бы это было так, поскольку это означает, что gettimeofday потребовалось бы 100-200 нс, а не 15-20 нс, поскольку он уже выполняет вызов ядра.
Хороший вопрос, страницы VDSO - это память ядра, отображаемая в пространство пользователя. Если вы один шаг в gettimeofday()видишь call на страницу VDSO, где используется некоторый код rdtsc и масштабирует результат с масштабными коэффициентами, которые он считывает с другой страницы данных.
Но эти страницы должны быть читаемыми из пространства пользователя, поэтому Linux может сохранять их отображение без какого-либо риска. Уязвимость Meltdown заключается в том, что бит U/S (пользователь / супервизор) в записях таблицы страниц / TLB не мешает непривилегированным нагрузкам (и другим зависимым инструкциям) происходить микроархитектурно, вызывая изменение состояния микроархитектуры, которое затем можно прочитать с кеш-таймингом.