kayot Опубликовано 19 ноября, 2013 · Жалоба Прибивать. И если нужно - использовать софтовую балансировку RPS/ISR. При размазывании с помощью irq_affinity происходит следующее - прерывание все так же обрабатывается 1 CPU, но каждое следующее планировщик кидает на следующий CPU. В итоге если мы упирались в скорость 1 ядра, мы так в него и упираемся, хотя в топе все красиво + идет постоянное вымывание кешей, трафика в таком варианте пролезет даже меньше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 19 ноября, 2013 · Жалоба Прибивать. И если нужно - использовать софтовую балансировку RPS/ISR. При размазывании с помощью irq_affinity происходит следующее - прерывание все так же обрабатывается 1 CPU, но каждое следующее планировщик кидает на следующий CPU. В итоге если мы упирались в скорость 1 ядра, мы так в него и упираемся, хотя в топе все красиво + идет постоянное вымывание кешей, трафика в таком варианте пролезет даже меньше. Можно поподробнее про вымывание кешей? Если я правильно понял - имеем, к примеру, 4 ядра и одно прерываение (один интерфейс). Прибиваем прерывание к к первому ядру, а rps ставим в f. Где будет узкое место? И какие подводные камни? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaktak Опубликовано 19 ноября, 2013 · Жалоба Прибивать. И если нужно - использовать софтовую балансировку RPS/ISR. При размазывании с помощью irq_affinity происходит следующее - прерывание все так же обрабатывается 1 CPU, но каждое следующее планировщик кидает на следующий CPU. В итоге если мы упирались в скорость 1 ядра, мы так в него и упираемся, хотя в топе все красиво + идет постоянное вымывание кешей, трафика в таком варианте пролезет даже меньше. Спасибо за ответ! RPS обязательно попробую, насколько я понял это позволяет распараллелить обработку пакета на верхних уровнях (IP/TCP) основываясь на хэше заголовков. В том числе в теории должно размазать нагрузку, создаваемую ipt_do_table. При размазывании с помощью irq_affinity происходит следующее - прерывание все так же обрабатывается 1 CPU, но каждое следующее планировщик кидает на следующий CPU. В итоге если мы упирались в скорость 1 ядра, мы так в него и упираемся Вот тут не совсем уловил... Если планировщик кидает каждое новое прерывание на следующий ЦПУ, то почему нет профита? Если не трудно - разжуйте на примере. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tamahome Опубликовано 19 ноября, 2013 · Жалоба Люди, а бондинг сильно грузит систему при большом трафике? Интересует 802.3ad L2+3 Разницы не заметил Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 19 ноября, 2013 · Жалоба Если планировщик кидает каждое новое прерывание на следующий ЦПУ, то почему нет профита? Если не трудно - разжуйте на примере. Потому что следующее прерывание не может быть запущено пока обработка предыдущего не завершится. Обычно - аппаратно реализуется (обработчик при выходе сбрасывает флаг запрета прерываний, установленный при входе в процедуру обработки). Зачем - а чтобы не было race condition и прочих прелестей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 19 ноября, 2013 · Жалоба Если планировщик кидает каждое новое прерывание на следующий ЦПУ, то почему нет профита? Если не трудно - разжуйте на примере. Потому что следующее прерывание не может быть запущено пока обработка предыдущего не завершится. Обычно - аппаратно реализуется (обработчик при выходе сбрасывает флаг запрета прерываний, установленный при входе в процедуру обработки). Зачем - а чтобы не было race condition и прочих прелестей. Не совсем. Обработчик прерываний состоит из двух частей (top and bottom half). Top half - это часть, которая делает минимально необходимый набор операций для снятия данных с устройства и сброс флага запрета прерываний. Эти вещи выполняются только тем процессором (ядром), к которому пришло аппаратное прерывание. Bottom half делает все остальные операции (распределение данных по структурам, пакетную фильтрацию, queueing и т.д.), которые вполне могут быть распараллелены, если написаны правильно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
micol Опубликовано 19 ноября, 2013 (изменено) · Жалоба На днях решил проапгрейдить bgp-софтроутер с центос 5 до 6 и параллельно накатить свеженькое ядро. Делал ночью, времени было в обрез :) Дано 2 шестиядерных E5645@2.40GHz, выключен HT, Intel S5520UR,охапка памяти, Intel 82599 двухпортовый SFP+ Залил Centos 6.4, обновил пакеты Подключил репозиторий elrepo, установил от туда ядро 3.12.0-1.el6.elrepo.x86_64 Скачал ixgbe-3.18.7-1, собрал RPM, указав в спеке к make флаг отключающий LRO: CFLAGS_EXTRA="-DIXGBE_NO_LRO" Установил собранный RPM со свежим модулем для 82999 Перезагрузил модуль ixgbe c options ixgbe LRO=0 FdirMode=0,0 DCA=2,2 MQ=1,1 RSS=0,0 InterruptThrottleRate=1,1 FCoE=0,0 filename: ixgbe.ko version: 3.18.7 license: GPL description: Intel(R) 10 Gigabit PCI Express Network Driver author: Intel Corporation, <linux.nics@intel.com> srcversion: B03433222E04D753B357EFB depends: hwmon,dca vermagic: 3.12.0-1.el6.elrepo.x86_64 SMP mod_unload modversions parm: InterruptType:Change Interrupt Mode (0=Legacy, 1=MSI, 2=MSI-X), default IntMode (deprecated) (array of int) parm: IntMode:Change Interrupt Mode (0=Legacy, 1=MSI, 2=MSI-X), default 2 (array of int) parm: MQ:Disable or enable Multiple Queues, default 1 (array of int) parm: DCA:Disable or enable Direct Cache Access, 0=disabled, 1=descriptor only, 2=descriptor and data (array of int) parm: RSS:Number of Receive-Side Scaling Descriptor Queues, default 0=number of cpus (array of int) parm: VMDQ:Number of Virtual Machine Device Queues: 0/1 = disable, 2-16 enable (default=8) (array of int) parm: max_vfs:Number of Virtual Functions: 0 = disable (default), 1-63 = enable this many VFs (array of int) parm: L2LBen:L2 Loopback Enable: 0 = disable, 1 = enable (default) (array of int) parm: InterruptThrottleRate:Maximum interrupts per second, per vector, (0,1,956-488281), default 1 (array of int) parm: LLIPort:Low Latency Interrupt TCP Port (0-65535) (array of int) parm: LLIPush:Low Latency Interrupt on TCP Push flag (0,1) (array of int) parm: LLISize:Low Latency Interrupt on Packet Size (0-1500) (array of int) parm: LLIEType:Low Latency Interrupt Ethernet Protocol Type (array of int) parm: LLIVLANP:Low Latency Interrupt on VLAN priority threshold (array of int) parm: FdirPballoc:Flow Director packet buffer allocation level: 1 = 8k hash filters or 2k perfect filters 2 = 16k hash filters or 4k perfect filters 3 = 32k hash filters or 8k perfect filters (array of int) parm: AtrSampleRate:Software ATR Tx packet sample rate (array of int) parm: FCoE:Disable or enable FCoE Offload, default 1 (array of int) parm: LRO:Large Receive Offload (0,1), default 1 = on (array of int) parm: allow_unsupported_sfp:Allow unsupported and untested SFP+ modules on 82599 based adapters, default 0 = Disable (array of int) Далее поставил bird, вернул к нему конфигурацию, запустил... Трафик пошел... Все отлично, но нагрузка естественно на одно ядро, т.к. все прерывания висят на 1-м ядре по умолчанию Отключил всяческие offload на сетевушках, увеличил ring до tx 4096 rx 4096... Раскидал прерывания скриптом set_irq_affinity, который раскидал 12 очередей RxTx на обеих портах сетевой карты "лесенкой" по ядрам. И вот тут начались чудеса. Пытаюсь протестировать скорость на forward - 2-4 Мбит/сек в один TCP поток. Смотрю ifconfig - вижу растущие дропы rx на обоих сетевых интерфейсах Торможу сеть, выгружаю ixgbe, загружаю ixgbe, повторяю все кроме раскидывания прерываний - дропов нет, скорость при тесте с удаленным сервером, воткнутым 1Гб/сек сетевушкой аккурат около 1Гбита/сек. Раскидываю прерывания - потери, тормоза со всеми вытекающими. Вернулся на родное Centos-овское ядро 2.6.32-358.23.2.el6.x86_64 с ядерным же модулем IXGBE 3.9.15-k - дропов нет, скорость в порядке. Но не устраивает загрузка ядер. top - 22:24:09 up 4 days, 15:16, 3 users, load average: 0.07, 0.06, 0.01 Tasks: 216 total, 1 running, 215 sleeping, 0 stopped, 0 zombie Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 77.1%id, 0.7%wa, 0.0%hi, 22.2%si, 0.0%st Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 78.0%id, 0.0%wa, 0.0%hi, 22.0%si, 0.0%st Cpu2 : 0.3%us, 0.0%sy, 0.0%ni, 76.3%id, 0.0%wa, 0.0%hi, 23.3%si, 0.0%st Cpu3 : 0.0%us, 0.0%sy, 0.0%ni, 78.3%id, 0.0%wa, 0.0%hi, 21.7%si, 0.0%st Cpu4 : 0.0%us, 0.0%sy, 0.0%ni, 74.8%id, 0.0%wa, 0.0%hi, 25.2%si, 0.0%st Cpu5 : 0.0%us, 0.0%sy, 0.0%ni, 80.1%id, 0.0%wa, 0.0%hi, 19.9%si, 0.0%st Cpu6 : 0.0%us, 0.0%sy, 0.0%ni, 75.6%id, 0.0%wa, 0.0%hi, 24.4%si, 0.0%st Cpu7 : 0.0%us, 0.0%sy, 0.0%ni, 78.3%id, 0.0%wa, 0.0%hi, 21.7%si, 0.0%st Cpu8 : 0.0%us, 0.0%sy, 0.0%ni, 78.7%id, 0.0%wa, 0.0%hi, 21.3%si, 0.0%st Cpu9 : 0.0%us, 0.0%sy, 0.0%ni, 57.1%id, 0.0%wa, 0.0%hi, 42.9%si, 0.0%st Cpu10 : 0.0%us, 0.0%sy, 0.0%ni, 77.8%id, 0.0%wa, 0.0%hi, 22.2%si, 0.0%st Cpu11 : 0.0%us, 0.0%sy, 0.0%ni, 79.4%id, 0.0%wa, 0.0%hi, 20.6%si, 0.0%st 20,23% [kernel] [k] _spin_lock 7,37% [ixgbe] [k] ixgbe_poll 6,46% [kernel] [k] memcpy 4,76% [ixgbe] [k] ixgbe_xmit_frame_ring 3,73% [kernel] [k] net_rx_action 3,14% [kernel] [k] dev_queue_xmit 2,64% [kernel] [k] ip_route_input 2,50% [kernel] [k] __napi_complete 2,13% [kernel] [k] fn_hash_lookup 1,95% [kernel] [k] irq_entries_start 1,76% [kernel] [k] skb_release_data 1,66% [kernel] [k] consume_skb 1,39% [kernel] [k] put_page 1,38% [kernel] [k] kmem_cache_free 1,36% [kernel] [k] pskb_expand_head 1,16% [kernel] [k] dma_issue_pending_all 1,09% [kernel] [k] __alloc_skb 1,06% [kernel] [k] kfree 0,94% [kernel] [k] swiotlb_sync_single 0,90% [kernel] [k] __netif_receive_skb 0,89% [kernel] [k] get_page 0,86% [kernel] [k] kmem_cache_alloc_node_trace 0,86% [kernel] [k] dev_hard_start_xmit 0,83% [kernel] [k] neigh_resolve_output 0,76% [kernel] [k] ip_rcv 0,76% [kernel] [k] __kmalloc 0,74% [8021q] [k] vlan_dev_hwaccel_hard_start_xmit 0,59% [kernel] [k] kmem_cache_alloc_node 0,58% [kernel] [k] __phys_addr 0,55% [kernel] [k] swiotlb_dma_mapping_error 0,52% [kernel] [k] vlan_gro_common 0,52% [kernel] [k] ip_finish_output 0,52% [kernel] [k] vlan_gro_receive При трафике 3/2 Гбита ~400-500 / 300-400Kpps Хотел было поиграть с 3.хх ядром, но не взлетело, время на эксперименты ночью особо не было, надо было вернуть трафик людям... Шейпера нет, iptables выгружен. Что я делаю не так? :) Изменено 19 ноября, 2013 пользователем micol Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 19 ноября, 2013 (изменено) · Жалоба Прибивать. И если нужно - использовать софтовую балансировку RPS/ISR. При размазывании с помощью irq_affinity происходит следующее - прерывание все так же обрабатывается 1 CPU, но каждое следующее планировщик кидает на следующий CPU. В итоге если мы упирались в скорость 1 ядра, мы так в него и упираемся, хотя в топе все красиво + идет постоянное вымывание кешей, трафика в таком варианте пролезет даже меньше. Можно поподробнее про вымывание кешей? Если я правильно понял - имеем, к примеру, 4 ядра и одно прерываение (один интерфейс). Прибиваем прерывание к к первому ядру, а rps ставим в f. Где будет узкое место? И какие подводные камни? В описанном вами варианте - никаких вымываний и проблем. А вот если привязать прерывание ко всем ядрам с помощью irq_affinity - будет бардак, постоянное переключение процессоров приводи к необходимости постоянной же синхронизации кешей и увеличенным cache miss при доступе к памяти. Если планировщик кидает каждое новое прерывание на следующий ЦПУ, то почему нет профита? Если не трудно - разжуйте на примере. Потому что следующее прерывание не может быть запущено пока обработка предыдущего не завершится. Обычно - аппаратно реализуется (обработчик при выходе сбрасывает флаг запрета прерываний, установленный при входе в процедуру обработки). Зачем - а чтобы не было race condition и прочих прелестей. Не совсем. Обработчик прерываний состоит из двух частей (top and bottom half). Top half - это часть, которая делает минимально необходимый набор операций для снятия данных с устройства и сброс флага запрета прерываний. Эти вещи выполняются только тем процессором (ядром), к которому пришло аппаратное прерывание. Bottom half делает все остальные операции (распределение данных по структурам, пакетную фильтрацию, queueing и т.д.), которые вполне могут быть распараллелены, если написаны правильно. В теории да. На практике - распараллеливание soft-irq(bottom half как вы описали) стало доступно не так давно, и реализуется RPS в linux или netisr в BSD. Если их не использовать - пакет все так же линейно проходит весь путь, от обработчика аппаратного прерывания и до выхода из всех цепочек фаервола/шейпера. Изменено 20 ноября, 2013 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 20 ноября, 2013 · Жалоба micol интеловская виртуализация и VT-d выключены? DMA engine из той же оперы, надо выключать на роутере. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
micol Опубликовано 20 ноября, 2013 · Жалоба micol интеловская виртуализация и VT-d выключены? DMA engine из той же оперы, надо выключать на роутере. Все что касаемо биоса выключено было еще во времена Centos 5 CONFIG_DMA_ENGINE=y? это вырубать я так понимаю? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 20 ноября, 2013 · Жалоба micol от этого DCA зависит, можно оставить, а выключить CONFIG_NET_DMA, CONFIG_ASYNC_TX_DMA и драйвера к IOH DMA и подобным. Hardware IOMMU туда же. Хотя может и не с этим связано, perf top выше - это от нового ядра, когда оно тормозит или от старого? Как вариант еще - проверить, что на интерфейсах multiq очереди, а не sfq какой-нибудь... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
micol Опубликовано 20 ноября, 2013 · Жалоба Хотя может и не с этим связано, perf top выше - это от нового ядра, когда оно тормозит или от старого? perf top от старого ядра со старым же ixgbe из состава от нового, к сожалению, не сохранил но там в топе были что-то вроде fib lookup и что-то от ixgbe irq bla bla bla Как вариант еще - проверить, что на интерфейсах multiq очереди, а не sfq какой-нибудь... Проверял, везде mq стоял и на новом ядре и на центосовском На новом то вот по нагрузке было хорошо, но были дропы при размазывании прерываний по ядрам, а это уже очень не хорошо( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 20 ноября, 2013 · Жалоба Вопрос в небольшой оффтоп. Если мы лимитируем скорость на входе интерфейса через police rate - какой выбирать бурст? В случае с Cisco предлагалась формула: Normal burst (bytes) = CommitedAccessRate(bits) * (1/8) * 1.5 Extended burst (bytes) = 2 * Normal burst Далее проведенный эксперимент. Ставим скорость 100Мбит, а бурст 500k. Запускаем iperf. Видим что-то около 100Мбит (96 емнип) и почти стабильно. В какой-то момент вдруг она может провалится до 30-40мбит и как правило сама прийти в чувство не может (видимо tcp с окном не определяется). Если тут же перезапустить iperf - скорость снова в норме. Еще вариант - передать iperf ключик гнать 4 параллельных потока - тогда тоже суммарно едет нормально. Берем рекомендации Cisco по Normal burst и получаем для 100Мбит где-то 18750Kb бурста. Ставим эту величину. Запускаем iperf в один поток. Скорость, которую кажет iperf пляшет в некотором небольшом диапазоне (92-114Мбит), но на интерфейсе по ethstats видим честные >=100Мбит. Внимание вопрос: кто какие значения подставляет в burst для police rate? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 20 ноября, 2013 · Жалоба micol можно еще txqueuelen на интерфейсах увеличить через ip link set до 10000 Вопрос в небольшой оффтоп. Если мы лимитируем скорость на входе интерфейса через police rate - какой выбирать бурст? такой, который устроит спидтест и ваших абонентов ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
micol Опубликовано 20 ноября, 2013 · Жалоба micol можно еще txqueuelen на интерфейсах увеличить через ip link set до 10000 Это тоже проделывалось. Вопрос по дропам все еще актуален. На сл. неделе попробую повторить апгрейд версии ядра. Верный совет бы очень пригодился Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 20 ноября, 2013 · Жалоба Подскажите, сетевые BCM5709c нормально работают? 2x2 стоят в сервере DL360G7, который хочу приспособить для NATа на скорости до гигабита. Видел только два упоминания на форуме, одно из которых в негативном контексте. Jumbo frame 9k, buffer up to 96kB выглядят пристойно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 21 ноября, 2013 · Жалоба Подскажите, сетевые BCM5709c нормально работают? 2x2 стоят в сервере DL360G7, который хочу приспособить для NATа на скорости до гигабита. Видел только два упоминания на форуме, одно из которых в негативном контексте. Jumbo frame 9k, buffer up to 96kB выглядят пристойно. Я помню, что у этих сетевух можно было поставить значительно меньшие размеры RX/TX rings, чем у Интеловских. Хотя может быть это была проблема с драйвером, и ее уже решили. Нужно сделать bonding по два порта и правильно раскидать прерывания по ядрам процессора, и тогда их вполне хватит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Painter Опубликовано 21 ноября, 2013 (изменено) · Жалоба А параметры ядра CONFIG_PREEMPT_* каким-либо образом влияют на роутинг и шейпинг? Изменено 21 ноября, 2013 пользователем Painter Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 21 ноября, 2013 · Жалоба Подскажите, сетевые BCM5709c нормально работают? 2x2 стоят в сервере DL360G7, который хочу приспособить для NATа на скорости до гигабита. Видел только два упоминания на форуме, одно из которых в негативном контексте. Jumbo frame 9k, buffer up to 96kB выглядят пристойно. Стоят такие в нескольких местах по два порта в bonding: 03:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) У них меньше ring buffer для tx: # ethtool -g eth0 Ring parameters for eth0: Pre-set maximums: RX: 4080 RX Mini: 0 RX Jumbo: 16320 TX: 255 Current hardware settings: RX: 1020 RX Mini: 0 RX Jumbo: 0 TX: 255 по сравнению с Intel 82576: # ethtool -g eth2 Ring parameters for eth2: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Других принципиальных отличий не увидел. Работают себе и есть не просят. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 21 ноября, 2013 (изменено) · Жалоба Стоят BCM5709c, работают и кушать не просят. Единственное что напрягает - драйвер. Там где у интеловского IGB можно выбрать число очередей, тут вариантов всего 2 - или включить MSI с автоматом(по числу ядер), или вообще выключить MSI!! В итоге на машине с 8 ядрами и 8 сетевками мне приходится держать 64 очереди :) Изменено 21 ноября, 2013 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 21 ноября, 2013 · Жалоба Спасибо за пояснения, кроме сомнения в сетевых картах вся остальная начинка максимально крутая, буду ставить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
srg555 Опубликовано 21 ноября, 2013 (изменено) · Жалоба Столкнулся с такой проблемой после обновления ядра(подадобились некоторые "новые" модули). ksoftirqd/2, ksoftirqd/3, kworker/2:1 утилизируют под 100% CPU. oprofile говорит: samples % image name app name symbol name 43839 23.6025 vmlinux vmlinux rb_prev 29677 15.9778 vmlinux vmlinux __alloc_and_insert_iova_range 12282 6.6125 vmlinux vmlinux find_iova 9638 5.1890 vmlinux vmlinux clflush_cache_range 5541 2.9832 vmlinux vmlinux add_unmap 5420 2.9181 pppoe.ko pppoe.ko get_item 4894 2.6349 vmlinux vmlinux __free_iova 3664 1.9727 vmlinux vmlinux iova_get_pad_size 2975 1.6017 vmlinux vmlinux sch_direct_xmit 2697 1.4520 vmlinux vmlinux __domain_mapping 2659 1.4316 vmlinux vmlinux __netif_receive_skb_core 2498 1.3449 vmlinux vmlinux fib_table_lookup 1818 0.9788 vmlinux vmlinux flush_unmaps 1434 0.7721 netxen_nic.ko netxen_nic.ko netxen_process_rxbuf 1365 0.7349 vmlinux vmlinux dev_queue_xmit 1245 0.6703 vmlinux vmlinux iommu_flush_dev_iotlb 1235 0.6649 vmlinux vmlinux rb_erase 1231 0.6628 vmlinux vmlinux kmem_cache_alloc 1206 0.6493 vmlinux vmlinux ip_finish_output 987 0.5314 vmlinux vmlinux eth_type_trans 967 0.5206 vmlinux vmlinux dma_pte_free_level 892 0.4802 vmlinux vmlinux vlan_do_receive 885 0.4765 vmlinux vmlinux mwait_idle_with_hints 869 0.4679 vmlinux vmlinux kmem_cache_free 866 0.4662 vmlinux vmlinux dma_pte_clear_range ... Нашёл вот такое http://forum.nag.ru/forum/index.php?showtopic=69706&view=findpost&p=644916 Собственно, функции из топа oprofile относятся к iommu. Достаточно ли добавить intel_iommu=off в параметры загрузки ядра или же нужно пересобирать ядро с CONFIG_DMAR_TABLE=n ? Ещё в dmesg есть такое: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at drivers/iommu/intel_irq_remapping.c:533 intel_irq_remapping_supported+0x35/0x75() This system BIOS has enabled interrupt remapping on a chipset that contains an erratum making that feature unstable. To maintain system stability interrupt remapping is being disabled. Please contact your BIOS vendor for an update Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.7-elrepocfg #1 Hardware name: HP ProLiant DL160 G6 , BIOS O33 05/01/2012 0000000000000215 ffff8802348edd28 ffffffff815fb0a7 0000000000000215 ffff8802348edd78 ffff8802348edd68 ffffffff8106707c ffffc90000c0e0c0 0000000000000246 00000000ffffffff 0000000000000000 000000000000b010 Call Trace: [<ffffffff815fb0a7>] dump_stack+0x49/0x62 [<ffffffff8106707c>] warn_slowpath_common+0x8c/0xc0 [<ffffffff8106710f>] warn_slowpath_fmt_taint+0x3f/0x50 [<ffffffff81d85755>] intel_irq_remapping_supported+0x35/0x75 [<ffffffff81513209>] irq_remapping_supported+0x29/0x50 [<ffffffff81d4aed4>] enable_IR+0x9/0x3e [<ffffffff81d4af9c>] enable_IR_x2apic+0x93/0x148 [<ffffffff81d4e9c2>] default_setup_apic_routing+0x15/0x6e [<ffffffff81d490d1>] native_smp_prepare_cpus+0x17a/0x280 [<ffffffff81d36b4c>] kernel_init_freeable+0x1ce/0x279 [<ffffffff815f2820>] ? rest_init+0x80/0x80 [<ffffffff815f282e>] kernel_init+0xe/0xf0 [<ffffffff8160826c>] ret_from_fork+0x7c/0xb0 [<ffffffff815f2820>] ? rest_init+0x80/0x80 ---[ end trace 1f6b0b957260ecf7 ]--- Изменено 21 ноября, 2013 пользователем srg555 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 25 ноября, 2013 · Жалоба https://www.mail-archive.com/e1000-devel@lists.sourceforge.net/msg06429.html When allocating DMA resources with the Intel IOMMU there is a walk through a spinlock protected red-black tree that is required. The problem is that it doesn't scale with multiple queues. I have seen it cause significant issues on systems with multiple cores. Выключайте VT-d и все сопутствующие навороты. Можно в биосе, можно не собирать драйвер, можно, наверно, опцией ядра. Вообще сходу и не скажу есть ли такая "волшабная фича", которую надо включить, чтобы стало лучше, а вот испортить всё - это пожалуйста. OK, SMP и NUMA - такие фичи, пожалуй всё :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
srg555 Опубликовано 25 ноября, 2013 · Жалоба Забыл отписаться. intel_iommu=off в параметрах ядра решило проблему. VT-d выключить не могу, оно в биосе, а удалённого монитора там нет и удалённой serial console, как и резервного канала, чтоб управлять им, когда он в перезагрузке :) Есть только удалённые руки, но проще выключить параметром ядра Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 26 ноября, 2013 · Жалоба Маленький оффтоп. Где-то здесь на форуме пробегала тема, где народ роутил линуксом 10-20-30...100500Гбит с какими-то самописными модулечками для форвардинга - не могу найти. Кто-то может ткнуть носом? Или ее снесли? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...