Загрузка процессора запрещает прерывания в Linux
У меня есть Ubuntu box с ядром 3.2, CPU с 2 ядрами и карта CAN (Controller Area Network) на основе контроллера SJA1000, подключенного через шину PCI.
Я тестирую возможности получения карты. Он может обрабатывать около 4000 пакетов в секунду, соответствующее прерывание также вызывается ~4000 раз в секунду (как показывает /proc/interrupts), и это не вызывает нагрузки на процессор в системе. Однако, если я сгенерирую искусственную нагрузку на процессор с помощью команды стресса:
chrt --idle 0 stress -c 2
прерывания больше не генерируются, и поэтому сообщения не принимаются.
Почему загрузка процессора сдерживает аппаратные прерывания и что с этим можно сделать?
2 ответа
Я подозреваю, что происходит то, что загрузка ЦП блокируется от прерываний, обслуживаемых ЦП.
Используйте itop, чтобы увидеть, что на самом деле происходит. Вывод этого поможет понять вашу проблему в дальнейшем.
Могут быть некоторые настройки BIOS, которые можно настраивать, но потребуется дополнительная информация, чтобы точно определить, какие настройки окажут наиболее значительное влияние.
Прерывания, необходимые для выхода из состояния HLT, на которое есть ссылка в этом ответе, кажутся интересными и, возможно, связанными? Исходя из характера стрессовой рабочей нагрузки и, если в системе включена гиперпоточность, некоторые из "виртуальных" процессоров, которые добавляются с помощью гиперпоточности, могут быть помещены в HLT состояние до тех пор, пока уровни нагрузки не будут снижены, и возможно, что аппаратное обеспечение решит игнорировать прерывания процессов, работающих на этих процессорах.
Низкоуровневые конфигурации оборудования в BIOS и ядре ОС могут оказать огромное влияние на многие аспекты производительности. Проверка того, что ваша система сконфигурирована для правильной обработки карт расширения (графика, связь и т. Д.) Любого рода, может быть серьезной проблемой. Дополнительные сведения о физическом оборудовании и настройках ядра, а также любые дополнительные журналы, такие как журнал событий сервера / системы (SEL) или запись данных датчика (SDR), будут полезны для дальнейшей диагностики проблемы с оборудованием низкого уровня, подобной этой.
SEL и SDR доступны на большинстве современных серверов, и к ним можно получить доступ с помощью ipmitool или множества других инструментов с открытым исходным кодом и проприетарных / предоставляемых вендором для управления сервером как внутри, так и вне диапазона.