2011-01-20 6 views
4

Если процесс прерывается аппаратным прерыванием (обработчик прерываний первого уровня), тогда планировщик ЦП становится осведомленным об этом (например, планирует ли время выполнения Планировщик для аппаратного обеспечения прерывания отдельно от прерванного процесса)?Является ли планировщик Linux осведомленным об аппаратных прерываниях (Scheduler Jitter)

Подробнее: Я пытаюсь устранить проблему, когда загрузка процессора в Htop является слишком низким для выполнения этой задачи определены шифрования пакетов (ЦП на < 10%, тогда как шифрование пакетов на 400Мб; Raw скорость шифрования только 1.6Gbps , поэтому шифрование пакетов не должно происходить быстрее, чем скорость необработанного шифрования).

Пояснение: Моя гипотеза заключается в том, что инкапсуляция пакетов происходит при аппаратных прерываниях, что дает мне иллюзию низкого использования ЦП в htop. Обычно FLIH реализуются так, что они как можно быстрее завершают свою задачу и откладывают свою работу на SLIH (обработчик прерываний второго уровня, который, как я полагаю, выполняется от имени ksoftirqd/X). Но что произойдет, если FLIH прерывает процесс в течение очень долгого времени? Означает ли это какой-то джиттер ОС?

Я использую Ubuntu 10.04.1 на платформе x86-64.

Дополнительная информация отладки:

while [ 1 ]; do cat /proc/stat | grep "cpu "; sleep 1; done; 
cpu 288 1 1677 356408 1145 0 20863 0 0 
cpu 288 1 1677 356772 1145 0 20899 0 0 
cpu 288 1 1677 357108 1145 0 20968 0 0 
cpu 288 1 1677 357392 1145 0 21083 0 0 
cpu 288 1 1677 357620 1145 0 21259 0 0 
cpu 288 1 1677 357972 1145 0 21310 0 0 
cpu 288 1 1677 358289 1145 0 21398 0 0 
cpu 288 1 1677 358517 1145 0 21525 0 0 
cpu 288 1 1678 358838 1145 0 21652 0 0 
cpu 289 1 1678 359141 1145 0 21704 0 0 
cpu 289 1 1678 359563 1145 0 21729 0 0 
cpu 290 1 1678 359886 1145 0 21758 0 0 
cpu 290 1 1678 360296 1145 0 21801 0 0 

Седьмой (или шестой номер столбца) столбец здесь я думаю, это время, проведенное внутри обработчиков прерываний Аппаратные средства (HTOP использует этот ргос файл для получения статистики). Мне интересно, закончится ли это как ошибка в Linux или драйвере. Когда я взял эти/proc/stat снимки, трафик шел со скоростью 500 Мбит/с и 500 Мбит/с.

+0

Это вопрос программирования? Я не могу сказать? – Gabe

+0

N.B. 'while [1];' проще писать как 'while:;' – user562374

+0

Bur harder read – hirschhornsalz

ответ

1

Учитывается время, затрачиваемое на обработчики прерываний.

htop показывает это в «си» (мягкое прерывание) и «привет» (жесткое прерывание). ni приятно, а wa io-wait.

Edit: От человека прок:

шестой столбец аппаратного времени IRQ

седьмой столбец softirq

восемь украден Время

nienth является гостевой время.

последние два имеют смысл только для виртуализованных систем.

У вас есть ядро, построенное с помощью CONFIG_IRQ_TIME_ACCOUNTING (Тип процессора и функции/Уровень детализации заданного уровня сложности IRQ)?

+0

Необработанная скорость шифрования, которую я указал, находится в битах, а не в байтах, и они определенно правильны (ЦП Q6600 и шифр aes-128). Есть ли инструмент, который показывает аппаратные прерывания рядом с процессами? Powertop, казалось, был одним из таких инструментов, но он не говорит мне, сколько времени он проводит внутри аппаратного обработчика прерываний, но только скорость, как часто они срабатывают. И% id в верхней части близок к ~ 95% во время инкапсуляции пакетов, поэтому что-то не учитывается правильно ... –

+0

Кажется, что вы предоставили очень близкий намек. Я приложил вывод cat/proc/stat, который принимался каждую секунду –

+0

Нет У меня нет CONFIG_IRQ_TIME_ACCOUNTING.Хотя я использую ядро ​​сервера Ubuntu. –