Кратко

  • Receive livelock возникает, когда прерывания приёма забирают время у протокола, передачи и приложения. Машина работает, но ни один пакет не завершает путь.
  • Mogul и Ramakrishnan сочетали прерывание для запуска опроса, круговое обслуживание, квоты, ранний сброс, обратную связь от следующих очередей и лимит CPU. Опрос без квоты тоже провалился.
  • Измерения проводились на медленной однопроцессорной DECstation и Ethernet 10 Мбит/с. Пять–десять пакетов за ход — результат той установки, а не современный универсальный параметр.

Машина работала, а результат исчезал

Прерывание пропускает аппаратное событие впереди обычной работы. При редких событиях это снижает задержку. При потоке выше возможностей цепочки приоритет способен помешать завершению уже принятых пакетов.

В модели 4.2BSD драйвер забирал пакет с интерфейса и ставил в очередь IP. Протокол обрабатывал его позже и с меньшим приоритетом, поэтому новая доставка могла снова его прервать. Заполненная очередь означала, что CPU продолжает тратиться на пакеты, которые не увидят ни приложение, ни выходной интерфейс.

Это не deadlock: после снижения входа система восстанавливалась. Но во время перегрузки CPU и счётчик прерываний выглядели активными при нулевой доставке. Авторы считали пропускной способностью лишь то, что дошло до конечного потребителя.

Приоритет прерываний стал скрытым планировщиком

Обычный планировщик почти не участвовал. Фиксированные уровни поставили приём выше протокола, завершения передачи, обслуживания маршрутов и пользовательских процессов.

Пакетирование прерываний уменьшало цену и отодвигало границу, но не давало выходу гарантированного хода. Быстрее принять — не значит завершить.

Прерывание будит, опрос распределяет

Изменённое ядро сохраняло прерывания при малой нагрузке. При высокой обработчик отмечал работу, будил поток опроса и оставлял новые прерывания замаскированными.

Поток по кругу посещал приём и передачу, выдавая callback квоту пакетов. После опустошения работа возвращалась к прерываниям. Принятый пакет продвигался как можно дальше, а не откладывался на ещё одной границе приоритетов.

Это гибрид. Постоянный опрос тратит CPU в тишине; чистые прерывания монополизируют насыщение. Первое событие обнаруживалось быстро, постоянный поток делился ограниченными ходами.

Без квоты опрос снова всё остановил

Без квоты приём всегда находил следующий пакет и не возвращал управление. Завершение передачи не выполнялось, дескрипторы не освобождались, выходная очередь заполнялась, а полезная скорость снова падала почти до нуля.

Монополия лишь сменила место. На этом оборудовании квота пять–десять пакетов давала устойчивый результат. Крупные партии экономили вызовы, но увеличивали задержку и риск голодания; для другой аппаратуры значение должно быть другим.

Сбрасывать до затрат и слушать следующую очередь

При перегрузке завершить всю нагрузку невозможно. Сброс на интерфейсе не расходует драйвер, протокол и очереди на обречённый пакет. Обратная связь сообщает входу, что следующая стадия больше не разгружается.

В опыте с screend вход останавливался при 75% заполнения, возобновлялся при 25%, а таймер около миллисекунды служил страховкой. Авторы называли числа произвольными. Переносимым был контур, а не пороги.

Другой механизм считал сетевые циклы в десятимиллисекундных окнах. После исчерпания доли приём уступал CPU приложениям и обслуживанию. Локальная реакция улучшалась, удалённая всё ещё страдала от потерь. Резерв времени не создаёт ёмкость.

Измерение неотделимо от стенда

Маршрутизатором была DECstation 3000/300 с Digital UNIX V3.2 — намеренно самый медленный доступный Alpha. Он связывал две свободные сети Ethernet 10 Мбит/с. Каждый опыт посылал 10 000 UDP-пакетов с четырьмя байтами данных; скорость была средним значением, а не точным темпом.

С исходным ядром и screend ухудшение начиналось выше примерно 2 000 пакетов/с, полный livelock — около 6 000. Без screend максимум был около 4 700. Отчёт запрещал экстраполяцию на быстрые LAN и CPU, не проверял настоящее SMP и не решал, какой пакет важнее сохранить.

Документация Linux NAPI и сегодня описывает похожую форму: прерывание планирует опрос, IRQ остаются закрытыми, а бюджет ограничивает цикл. Это полезное сравнение, но не доказательство одинаковой причины любой современной перегрузки.

Google Research связывает карьеру Mogul с DEC/Compaq WRL, HP Labs и сетевой инфраструктурой Google. Работа остаётся совместной с Ramakrishnan. Её правило жёстко: занятость входа нельзя называть производительностью, если выход ничего не получает.

Источники