[kayot]

Прибивать. И если нужно - использовать софтовую балансировку RPS/ISR.

При размазывании с помощью irq_affinity происходит следующее - прерывание все так же обрабатывается 1 CPU, но каждое следующее планировщик кидает на следующий CPU.

В итоге если мы упирались в скорость 1 ядра, мы так в него и упираемся, хотя в топе все красиво + идет постоянное вымывание кешей, трафика в таком варианте пролезет даже меньше.

[heap]

Прибивать. И если нужно - использовать софтовую балансировку RPS/ISR.

При размазывании с помощью irq_affinity происходит следующее - прерывание все так же обрабатывается 1 CPU, но каждое следующее планировщик кидает на следующий CPU.

В итоге если мы упирались в скорость 1 ядра, мы так в него и упираемся, хотя в топе все красиво + идет постоянное вымывание кешей, трафика в таком варианте пролезет даже меньше.

 

Можно поподробнее про вымывание кешей? Если я правильно понял - имеем, к примеру, 4 ядра и одно прерываение (один интерфейс). Прибиваем прерывание к к первому ядру, а rps ставим в f. Где будет узкое место? И какие подводные камни?

[kaktak]

Прибивать. И если нужно - использовать софтовую балансировку RPS/ISR.

При размазывании с помощью irq_affinity происходит следующее - прерывание все так же обрабатывается 1 CPU, но каждое следующее планировщик кидает на следующий CPU.

В итоге если мы упирались в скорость 1 ядра, мы так в него и упираемся, хотя в топе все красиво + идет постоянное вымывание кешей, трафика в таком варианте пролезет даже меньше.

 

Спасибо за ответ! RPS обязательно попробую, насколько я понял это позволяет распараллелить обработку пакета на верхних уровнях (IP/TCP) основываясь на хэше заголовков. В том числе в теории должно размазать нагрузку, создаваемую ipt_do_table.

 

 

При размазывании с помощью irq_affinity происходит следующее - прерывание все так же обрабатывается 1 CPU, но каждое следующее планировщик кидает на следующий CPU.

В итоге если мы упирались в скорость 1 ядра, мы так в него и упираемся

Вот тут не совсем уловил... Если планировщик кидает каждое новое прерывание на следующий ЦПУ, то почему нет профита? Если не трудно - разжуйте на примере.

[Tamahome]

Люди, а бондинг сильно грузит систему при большом трафике? Интересует 802.3ad L2+3

Разницы не заметил

[NiTr0]

Если планировщик кидает каждое новое прерывание на следующий ЦПУ, то почему нет профита? Если не трудно - разжуйте на примере.

Потому что следующее прерывание не может быть запущено пока обработка предыдущего не завершится. Обычно - аппаратно реализуется (обработчик при выходе сбрасывает флаг запрета прерываний, установленный при входе в процедуру обработки). Зачем - а чтобы не было race condition и прочих прелестей.

[photon]

Если планировщик кидает каждое новое прерывание на следующий ЦПУ, то почему нет профита? Если не трудно - разжуйте на примере.

Потому что следующее прерывание не может быть запущено пока обработка предыдущего не завершится. Обычно - аппаратно реализуется (обработчик при выходе сбрасывает флаг запрета прерываний, установленный при входе в процедуру обработки). Зачем - а чтобы не было race condition и прочих прелестей.

Не совсем. Обработчик прерываний состоит из двух частей (top and bottom half). Top half - это часть, которая делает минимально необходимый набор операций для снятия данных с устройства и сброс флага запрета прерываний. Эти вещи выполняются только тем процессором (ядром), к которому пришло аппаратное прерывание. Bottom half делает все остальные операции (распределение данных по структурам, пакетную фильтрацию, queueing и т.д.), которые вполне могут быть распараллелены, если написаны правильно.

[micol]

На днях решил проапгрейдить 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

[kayot]

Прибивать. И если нужно - использовать софтовую балансировку 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

[vitalyb]

micol

интеловская виртуализация и VT-d выключены? DMA engine из той же оперы, надо выключать на роутере.

[micol]

micol

интеловская виртуализация и VT-d выключены? DMA engine из той же оперы, надо выключать на роутере.

 

Все что касаемо биоса выключено было еще во времена Centos 5

 

CONFIG_DMA_ENGINE=y? это вырубать я так понимаю?

[vitalyb]

micol

от этого DCA зависит, можно оставить, а выключить CONFIG_NET_DMA, CONFIG_ASYNC_TX_DMA и драйвера к IOH DMA и подобным. Hardware IOMMU туда же.

 

Хотя может и не с этим связано, perf top выше - это от нового ядра, когда оно тормозит или от старого?

 

Как вариант еще - проверить, что на интерфейсах multiq очереди, а не sfq какой-нибудь...

[micol]

Хотя может и не с этим связано, perf top выше - это от нового ядра, когда оно тормозит или от старого?

 

perf top от старого ядра со старым же ixgbe из состава

от нового, к сожалению, не сохранил но там в топе были что-то вроде fib lookup и что-то от ixgbe irq bla bla bla

 

Как вариант еще - проверить, что на интерфейсах multiq очереди, а не sfq какой-нибудь...

 

Проверял, везде mq стоял и на новом ядре и на центосовском

 

На новом то вот по нагрузке было хорошо, но были дропы при размазывании прерываний по ядрам, а это уже очень не хорошо(

[heap]

Вопрос в небольшой оффтоп. Если мы лимитируем скорость на входе интерфейса через 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?

[vitalyb]

micol

можно еще txqueuelen на интерфейсах увеличить через ip link set до 10000

 

Вопрос в небольшой оффтоп. Если мы лимитируем скорость на входе интерфейса через police rate - какой выбирать бурст?

такой, который устроит спидтест и ваших абонентов )

[micol]

micol

можно еще txqueuelen на интерфейсах увеличить через ip link set до 10000

 

 

Это тоже проделывалось. Вопрос по дропам все еще актуален. На сл. неделе попробую повторить апгрейд версии ядра. Верный совет бы очень пригодился

[Sonne]

Подскажите, сетевые BCM5709c нормально работают? 2x2 стоят в сервере DL360G7, который хочу приспособить для NATа на скорости до гигабита. Видел только два упоминания на форуме, одно из которых в негативном контексте.

 

Jumbo frame 9k, buffer up to 96kB выглядят пристойно.

[photon]

Подскажите, сетевые BCM5709c нормально работают? 2x2 стоят в сервере DL360G7, который хочу приспособить для NATа на скорости до гигабита. Видел только два упоминания на форуме, одно из которых в негативном контексте.

 

Jumbo frame 9k, buffer up to 96kB выглядят пристойно.

Я помню, что у этих сетевух можно было поставить значительно меньшие размеры RX/TX rings, чем у Интеловских. Хотя может быть это была проблема с драйвером, и ее уже решили. Нужно сделать bonding по два порта и правильно раскидать прерывания по ядрам процессора, и тогда их вполне хватит.

[Painter]

А параметры ядра CONFIG_PREEMPT_* каким-либо образом влияют на роутинг и шейпинг?

Изменено 21 ноября, 2013 пользователем Painter

[heap]

Подскажите, сетевые 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

 

Других принципиальных отличий не увидел. Работают себе и есть не просят.

[kayot]

Стоят BCM5709c, работают и кушать не просят. Единственное что напрягает - драйвер.

Там где у интеловского IGB можно выбрать число очередей, тут вариантов всего 2 - или включить MSI с автоматом(по числу ядер), или вообще выключить MSI!!

В итоге на машине с 8 ядрами и 8 сетевками мне приходится держать 64 очереди :)

Изменено 21 ноября, 2013 пользователем kayot

[Sonne]

Спасибо за пояснения, кроме сомнения в сетевых картах вся остальная начинка максимально крутая, буду ставить.

[srg555]

Столкнулся с такой проблемой после обновления ядра(подадобились некоторые "новые" модули). 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

[vitalyb]

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 - такие фичи, пожалуй всё :)

[srg555]

Забыл отписаться. intel_iommu=off в параметрах ядра решило проблему. VT-d выключить не могу, оно в биосе, а удалённого монитора там нет и удалённой serial console, как и резервного канала, чтоб управлять им, когда он в перезагрузке :) Есть только удалённые руки, но проще выключить параметром ядра

[heap]

Маленький оффтоп. Где-то здесь на форуме пробегала тема, где народ роутил линуксом 10-20-30...100500Гбит с какими-то самописными модулечками для форвардинга - не могу найти. Кто-то может ткнуть носом? Или ее снесли?