Использование процессора в режиме опроса
Для нашего проекта, написанного на c ++, мы запускаем ядра процессора в режиме опроса, чтобы опрашивать драйвер (dpdk), но в режиме опроса загрузка процессора отображается как 100% в top / htop. Когда мы начали замечать сбой отбрасывания пакетов, подсчитали количество циклов или опросов, выполняемых в секунду на ядре (зависит от скорости и типа процессора).
Пример кода, используемого для расчета количества запросов в секунду с использованием функции опроса драйвера и без нее, приведен ниже.
#include <iostream>
#include <sys/time.h>
int main() {
unsigned long long counter;
struct timeval tv1, tv2;
gettimeofday(&tv1, NULL);
gettimeofday(&tv2, NULL);
while(1) {
gettimeofday(&tv2, NULL);
//Some function here to measure the overhead
//Poll the driver
if ((double) (tv2.tv_usec - tv1.tv_usec) / 1000000 + (double) (tv2.tv_sec - tv1.tv_sec) > 1.0) {
std::cout << std::dec << "Executions per second = " << counter << " per second" << std::endl;
counter = 0;
gettimeofday(&tv1, NULL);
}
counter++;
}
}
Результаты подсчета опросов различны, иногда мы видим сбой, и число снижается на 50% или ниже, чем при обычном подсчете, хотя это может быть проблемой с Linux, планируя задачу так,
Выделите ядра с помощью командной строки Linux (isolcpus = …), установите сходство, увеличьте приоритет процесса / потока до максимального значения и введите в реальном времени (RT)
Но без разницы.
Так что вопросы,
Можем ли мы рассчитывать на количество циклов / опросов в секунду, выполняемых на ядре процессора в режиме опроса?
Есть ли способ рассчитать загрузку ЦП в режиме опроса, так как загрузка ЦП ядра составляет 100% сверху?
Это правильный подход к этой проблеме?
Среда:
- Процессор Intel (R) Xeon (R) E5-2680 v3 @ 2,50 ГГц
- 8G оперативной памяти
- Виртуальная машина Ubuntu на гипервизоре Vmware.
Не уверен, что на этот вопрос уже был дан ответ, любые ссылки будут полезны.
Решение
Нет, вы не можете полагаться на «количество циклов / опросов в секунду, выполненных на ядре процессора в режиме опроса».
Это фундаментальный аспект среды выполнения в традиционной операционной системе, такой как та, которую вы используете: основной Linux.
В любое время может быть запущена тяжелая работа cron, которая требует немедленных требований к некоторым ресурсам, и планировщик ядра решает выгрузить ваше приложение и сделать что-то еще. Это было бы лишь одной из сотен возможных причин, по которым ваш процесс прерывался.
Даже если вы работаете от имени пользователя root, вы не будете полностью контролировать ресурсы вашего процесса.
Тот факт, что вы видите такое большое, случайное несоответствие в ваших показателях опроса, должен быть большим, сигнальным ключом: многозадачные операционные системы не работают таким образом.
Существуют другие операционные системы «реального времени», в которых приложения пользовательского пространства могут иметь определенные гарантии «уровня обслуживания», то есть минимальные доступные ресурсы ЦП или В / В, на которые можно положиться, чтобы гарантировать минимальное число случаев, когда конкретная кодовая последовательность может быть выполнено, в секунду или какой-либо другой показатель.
В Linux есть несколько вещей, с которыми можно поиграться, например, процесс nice уровень и еще несколько вещей. Но это все равно не даст вам никаких абсолютных гарантий.
Тем более, что вы даже не работаете на голом металле, а работаете внутри виртуального гипервизора. Таким образом, на ваш фактический профиль выполнения влияет не только операционная система вашего хоста, но и ваша гостевая операционная система!
Единственный способ гарантировать тот тип метрики, который вы ищете, это использовать операционную систему реального времени вместо Linux. Несколько лет назад я слышал о расширениях ядра Linux в реальном времени (Google food: «linux rtos»), но в последнее время мало что слышал об этом. Я не верю, что основные дистрибутивы Linux включают это расширение ядра, поэтому, если вы хотите пойти по этому пути, вы будете сами по себе.
Другие решения
современный linux на процессоре Intel обеспечивает способы заставить цикл опроса полностью занимать ядро процессора почти на 100%. Вещи, которые вы не учли, — это удалить системный вызов, который вызовет переключение контекста, отключить гиперпоточность или не использовать другой поток в той же строке кэша, отключить динамическое повышение частоты процессора в BIOS, убрать обработку прерываний.
detector