LINUX.ORG.RU
ФорумAdmin

Прерывания не разбрасываются по ядрам


0

1

/proc/irq/<NUM>/smp_affinity стоит в fff, а прерывания все почему-то на первом ядре обрабатываются:

# cat /proc/interrupts
            CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       CPU8       CPU9       CPU10      CPU11
...
 108:      38395          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-0
 109:      29554          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-1
 110:      11132          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-2
 111:      12340          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-3
 112:      10432          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-4
 113:      14631          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-5
 114:      19229          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-6
 115:      21373          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-7
...
Сервер - 2x6 ядер Xeon X5650 в NUMA, в ядре врубил Sparse IRQ, может в нем дело?

P.S. И еще странность - если сделать к примеру echo 2 > /proc/irq/108/smp_affinity, а потом обратно echo fff > /proc/irq/108/smp_affinity, то прерывания продолжают идти только на втором ядре.

прибейте прерывание каждой очереди к отдельному ядру - это более производительео чем размазывание по всем ядрам.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Да, я в курсе, и в итоге я этим займусь. Я не пойму почему ядро по умолчанию их не размазывает по всем ядрам. Дома у меня например сервак с тем же ядром распределяет прерывания по всем 4 ядрам равномерно.

blind_oracle ★★★★★ ()
Ответ на: комментарий от GotF

Ну это аналог ручного управления прерываниями :) Я просто хочу понять почему имея битовую маску FFF ядро всё равно лепит прерывания на 1 ядро.

blind_oracle ★★★★★ ()

может

[ megabaks@desktop ] ~ $ cat /proc/interrupts
           CPU0       CPU1       
  0:        464        339   IO-APIC-edge      timer
  1:      39758      39652   IO-APIC-edge      i8042
  8:         47         44   IO-APIC-edge      rtc0
  9:          0          0   IO-APIC-fasteoi   acpi
 16:    6692382    6692368   IO-APIC-fasteoi   ahci, uhci_hcd:usb3, nvidia
 17:    1735278    1735756   IO-APIC-fasteoi   pata_jmicron, eth1
 18:     416478     416929   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8
 19:          0          0   IO-APIC-fasteoi   uhci_hcd:usb7
 21:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
 22:    1260641    1259844   IO-APIC-fasteoi   ata_piix, ata_piix, hda_intel
 23:          0          0   IO-APIC-fasteoi   ehci_hcd:usb2, uhci_hcd:usb6
NMI:          0          0   Non-maskable interrupts
LOC:  250891993  248429395   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:          0          0   Performance monitoring interrupts
IWI:          0          0   IRQ work interrupts
RES:    4924598    4803703   Rescheduling interrupts
CAL:      59101      63320   Function call interrupts
TLB:    3367471    3376715   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
MCE:          0          0   Machine check exceptions
MCP:        685        685   Machine check polls
ERR:          1
MIS:          0
[ megabaks@desktop ] ~ $ zgrep IRQ /proc/config.gz 
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
CONFIG_HAVE_GENERIC_HARDIRQS=y
# IRQ subsystem
CONFIG_GENERIC_HARDIRQS=y
# CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED is not set
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
# CONFIG_AUTO_IRQ_AFFINITY is not set
# CONFIG_IRQ_PER_CPU is not set
# CONFIG_HARDIRQS_SW_RESEND is not set
# CONFIG_SPARSE_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
# CONFIG_INLINE_READ_UNLOCK_IRQ is not set
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
CONFIG_HT_IRQ=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
[ megabaks@desktop ] ~ $ 

megabaks ★★★★ ()

Нашел сервер с X5660 - по идее только в частоте разница, у меня похоже та же песня

root@jupiter:~# cat /proc/interrupts  | grep eth1-tx-0
4468:     491419          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  xen-pirq-msi-x     eth1-tx-0

Ядро 2.6.32-5-xen-amd64. Попробую еще глянуть на другой системе где тоже igb драйвер но другие процессоры, мне почему то кажется что дело в igb. Вы юзаете родной драйвер который в ванильном ядре?

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Возможно что для NUMA прерывания не размазываются именно для избежания деградации производительности.

PS: На E6800 c igb 2.4.13 все размазывается. Система из прошлого моего поста работает с igb 1.3.16-k2

ventilator ★★★ ()
Ответ на: комментарий от zgen

По идее не должно быть разницы.

ну я перед тем как написать погуглил и пришёл к выводу что это может быть связано. В инете написано что при NUMA ядро выбирается не случайно а на том на котором это быстрее всё работать будет. Лучше сам погугли, из меня плохой пересказчик.

true_admin ★★★★★ ()
Ответ на: комментарий от ventilator

Дело в том что не размазываются не только igb прерывания, а вообще ВСЕ. Если бы только igb, то вопросов бы не возникло. Драйвер igb я юзаю интелевский внешний, т.к. в ванильном вообще опций никаких нету, да и LRO тоже. И каждую сетевуху я опцией модуля Node= привязываю к определенной NUMA-ноде.

igb.InterruptThrottleRate=1,1 \
igb.IntMode=2,2 \
igb.RSS=8,8 \
igb.VMDQ=0,0 \
igb.max_vfs=0,0 \
igb.QueuePairs=1,1 \
igb.Node=0,1 \
ixgbe.RSS=12,12,12,12,12,12 \
ixgbe.MQ=1,1,1,1,1,1 \
ixgbe.DCA=2,2,2,2,2,2 \
ixgbe.VMDQ=0,0,0,0,0,0 \
ixgbe.IntMode=2,2,2,2,2,2 \
ixgbe.InterruptThrottleRate=1,1,1,1,1,1 \
ixgbe.RxBufferMode=0,0,0,0,0,0 \
ixgbe.FdirMode=0,0,0,0,0,0 \
ixgbe.Node=0,1,0,1,0,1 \
ixgbe.L2LBen=0,0,0,0,0,0

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от zgen

Нынешние процы имеют ведь встроенный контроллер памяти, и у каждого проца есть своя, локальная, память и память соседа, доступ к которой идёт через чипсет, и, соответственно, гораздо медленнее. Это и есть NUMA - каждый проц со своими мозгами - одна нода. И память устройства себе аллокируют на том или ином процессоре соответственно. Так что обработка прерываний должна идти на том проце ИМХО, где устройство угнездилось :)

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

Напутал, связь процов идёт напрямую через QPI, а не через чипсет, ну сути это не меняет.

blind_oracle ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.