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



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



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



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



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



  • 2 werter

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

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

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

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



  • Печально (



  • От поллинга будут отказываться в будущих версиях 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 не хуже и более естественен.



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


Log in to reply