Нежелательная задержка, когда поток ядра выполняет больше коммуникационной работы - PullRequest
Новая
       27

Нежелательная задержка, когда поток ядра выполняет больше коммуникационной работы

0 голосов
/ 28 ноября 2018

Мы разработали модуль ядра, который работает в основном как трафик проводной связи (eth, ...) - мост WiFi.Периодически он пересылает входящие проводные данные в WiFi и наоборот.Система состоит из двух устройств, работающих под управлением одного модуля ядра.При определенных условиях мы наблюдаем нежелательную задержку.

Модуль запускает поток ядра, который в основном выполняет: 

while(1) {
    schedule()
    do_bridge_work()
    usleep_range(200, 500)
}

Во время нормальной работы команда top отображает: 

CPU:   0% usr  19% sys   0% nic  60% idle   0% io   0% irq  19% sirq 
Load average: 1.03 1.06 1.01 1/54 491
PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
491    2 root        DW     0   0%  29% [bridge_thread]
3      2 root        SW     0   0%  10% [ksoftirqd/0]

Когда диагностика активирована, поток также отправляет дополнительные диагностические проводные эти пакеты.В этом режиме пинг устройств с одной стороны на другую происходит от 5-6 мс до 45-900 мс.top затем показывает: 

CPU:   0% usr  25% sys   0% nic  50% idle   0% io   0% irq  24% sirq 
Load average: 1.06 1.07 1.01 1/54 491
PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
491    2 root        DW     0   0%  35% [bridge_thread]
3      2 root        SW     0   0%  14% [ksoftirqd/0]

Если дополнительный schedule() вставлен перед usleep_range() или если время ожидания увеличено, это резко уменьшает задержку.Я думаю, что я сузил его, чтобы сделать вывод, что RX softirq не получает время планирования, необходимое для обработки входящего трафика (NET_RX_SOFTIRQ).Это основано на том факте, что время передачи переданных пакетов совершенно нормально.

Мои вопросы:

1: Почему время пинга увеличивается из-за увеличения работы в do_bridge_work() (больше обработкии дополнительная передача пакетов).NET_RX_SOFTIRQ вероятно голодает?

2: Почему время пинга уменьшается, когда добавляется дополнительный schedule() или когда увеличивается время ожидания?Означает ли это, что 200-500 млн. Долл. США недостаточно для обработки всех ожидающих программных вычислений, а более низкие программные средства голодают?Означает ли эффект добавления дополнительного schedule() то же самое, что позволяет другим выполнять больше работы за счет увеличения времени ожидания?

Версия ядра - 4.1.38, настроенная с NO_HZ, PREEMPT = y.

...