(Решено) Загрузка CPU при включенном поллинге

QWERTik

Имеется машинка на 865 чипсете, RAM=1Гиг, CPU=нортвуд-3,06ГГц (гипертрединг включен), сеть (2 интерфейса=WAN, LAN)=Intel 100 Pro, система=pfsense nanoBSD 2.0.3, свежеустановленная, мастера (кроме начального конфигуратора) не выполнялись, правила не создавались.
Суть вопроса: при выключенном поллинге загрузка процессора не превышает 3-5% даже при прокачке трафика в 5 килопакетов/с. При включенном поллинге загрузка процессора возрастает до 50-53% и держится на таком уровне даже при практически нулевом проходящем трафике (пара десятков tcp-сессий и несколько килобит трафика). Как это понимать???

werter

А гипертрейдинг пробовали отключать ? БИОС обновить попробуйте.

QWERTik

БИОС на маме изначально последний. Гипертрединг отключил и…... получил то, что в принципе ожидал: то, что при включенном поллинге (при включенном гипертрединге) ядро системы умело раскидывало по двум вычислительным конвейерам процессора (давая его загрузку на 48-53%), при выключенном гипертрединге полилось в один конвейер и как следствие - стабильная загрузка процессора на 100%. Прокачка трафика в это время не превышала 400 Кбит/с, т.е. трафик ни в коем случае не грузил систему. При этом возрасло и время отклика шлюза (RTT) c 0,8mS (min) до 1,2-1,3 mS (min) и естественно, пошли притормозы при сёрфе (и это неспешно, в одну харю на 100 Мбит/с канале)! При отключении - загрузка возвращается в норму (1-3%). При повторении эксперимента - всё повторяется на 100%. Делаю вывод, что это системный баг.
Вот мне и хотелось бы узнать - чем поллинг так грузит процессор периодически вычитывая практически пустые буфера сетевых интерфейсов в оперативу???!!! Получается, что прерывания не так "штормят" под нагрузкой, как призваный усмирить их поллинг!
Какой-то бред!

werter

У вас Реалтек?

aleksvolgin

2 werter

У вас Реалтек?

сеть (2 интерфейса=WAN, LAN)=Intel 100 Pro

Делаю вывод, что это системный баг

Правильный вывод.

QWERTik

Печально (

dvserg

От поллинга будут отказываться в будущих версиях FreeBSD http://skeletor.org.ua/?p=1418

Как заявляют разработчики – они уходят от polling’a.
…
Почти все современные сетевые адаптеры для 1000baseTx имеет feature называемую “interrupt coalescing”, задерживающую вызов прерывания до заполнения Rx кольца адаптера.

Третье обстоятельство – это так называемый direct dispatch. Если вы помните, докладчик упоминал об отдельном процессе netisr, предназначенном для обработки Rx фреймов. Причина существования netisr
– тот факт, что прерывание от Rx может прийти в момент, когда процессор уже выполняет сетевой код, и полная обработка пакета из interrupt handler привела бы к рекурсивному входу в сетевой стек. Альтернативой
было бы поднять приоритет процессора до splnet (в терминах OpenBSD), но это бы означало, что прерывания блокированы на длительное время.

Но, поскольку FreeBSD выполняет настоящий обработчик прерывания в отдельной нитке, то netisr не нужен. Все обработка входящего пакета можеть произойти без дорогостоящего переключения контекста. Это и есть direct dispatch. Direct dispatch включен по умолчанию на FreeBSD >= 7:
net.isr.direct: 1

Нетрудно видеть, что комбинация всех трех упомянутых архитектурных элементов эквивалентна pollingу и даже эффективнее его.

Конечно, есть сетевые карты, для которых polling выигрывает, но тенденция состоит в том, что direct dispatch не хуже и более естественен.

QWERTik

Ага, ну тогда всё сходится - конфликт процессов.
Спасибо за пояснения.