Dotaz: ksoftirqd vytezuje CPU

[ironman]

Preji pekny den, mam problem se zatezovanim CPU procesem ksoftirqd. Ten je schpny "sezrat" i 50% CPU. Tim se stava PC strasne pomale. Ve vypisu preruseni sem zjistil, ze sitovka Realtek RTL8111/8168B vyuziva jen jedno jadro - drivery mam od realteku 8.029.00-NAPI prelozene ze zdrojaku jelikoz s puvodnim z CentOSu sitovka obcas nenajela.

vypis lspci -v:

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
	Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard
	Physical Slot: 33
	Flags: bus master, fast devsel, latency 0, IRQ 36
	I/O ports at d800 [size=256]
	Memory at f8fff000 (64-bit, prefetchable) [size=4K]
	Memory at f8ff8000 (64-bit, prefetchable) [size=16K]
	Expansion ROM at fbdf0000 [disabled] [size=64K]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [70] Express Endpoint, MSI 01
	Capabilities: [ac] MSI-X: Enable- Count=4 Masked-
	Capabilities: [cc] Vital Product Data
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Virtual Channel 
	Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
	Kernel driver in use: r8168
	Kernel modules: r8168, r8169

vypis preruseni cat /proc/interupts

           CPU0       CPU1       CPU2       CPU3       
  0:        144          9          2          1   IO-APIC-edge      timer
  1:          0          1          1          0   IO-APIC-edge      i8042
  8:          1          0          0          0   IO-APIC-edge      rtc0
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          1          0          1          2   IO-APIC-edge      i8042
 14:       2342       2661       2500       2455   IO-APIC-edge      ata_piix
 15:          0          0          0          0   IO-APIC-edge      ata_piix
 16:        232         77        220         77   IO-APIC-fasteoi   uhci_hcd:usb5
 18:      25566          7      23446          3   IO-APIC-fasteoi   uhci_hcd:usb4, pata_jmicron
 19:         46       1192         42        354   IO-APIC-fasteoi   uhci_hcd:usb3
 23:         55      64149         53      63777   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
 24:          0          0          0          0   PCI-MSI-edge      pciehp
 25:          0          0          0          0   PCI-MSI-edge      pciehp
 26:          0          0          0          0   PCI-MSI-edge      pciehp
 27:          0          0          0          0   PCI-MSI-edge      pciehp
 36:          7        654      13788       2417   PCI-MSI-edge      eth0        ---- cita vzdy jen jeden counter
 37:          1          0          0          0   PCI-MSI-edge      xhci_hcd
 38:          0          0          0          0   PCI-MSI-edge      xhci_hcd
 39:          0          0          0          0   PCI-MSI-edge      xhci_hcd
 40:          0          0          0          0   PCI-MSI-edge      xhci_hcd
 41:          0          0          0          0   PCI-MSI-edge      xhci_hcd
NMI:        210        128        210        128   Non-maskable interrupts
LOC:     214662     182634     196572     189583   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:        210        128        210        128   Performance monitoring interrupts
PND:          0          0          0          0   Performance pending work
RES:       6568       6021       3042       7701   Rescheduling interrupts
CAL:      16557      18081      12972      15110   Function call interrupts
TLB:       3141       2486       6117       5248   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:         17         17         17         17   Machine check polls

dalsi zvlastni vec je, ze cita treba counter ctvrteho jadra, ale v /proc/irq/36/smp_affinity je cislo 8. A co jsem vygooglil melo by tam byt pocet jader. Kdyz sem tam vsak dal 4 tak se to chova stejne.

Odpovědi

[bman]

- mozes nainstalovat daemona "irqbalance", ktory by sa mal postarat o "spravodlivo automaticke" rozhadzovanie IRQ medzi procesory

- kukni este do /proc/softirqs a je tam nieco ako NET_RX a NET_TX. Malo by tam byt aspon trocha spravodlive rozdelenie medzi jednotlive CPU

- to co si napisal, ze 8 v smp_affinity je spravne. Vtedy to rozhadzuje len na jedno (stvrte CPU). Ak to chces na quadcore rozhadzovat medzi vsetky CPU, malo by tam byt f (kukni sem.)

BTW:

niektore moderne sietovky maju niekolko IO front, zaberu si napr. 8 IRQ zo systemu (kazda IO fronta jedno IRQ) a v tom pripade, je velmi vhodne aby smp afinita fungovala naozaj spravne

[ironman]

Sem tam zapomel napsat irqbalance mam samozrejme naisntalovany.

root      1427  0.0  0.0   9136   548 ?        Ss   09:55   0:01 irqbalance

Vystup ze softirqs:

cat /proc/softirqs 
                CPU0       CPU1       CPU2       CPU3       
      HI:          0          0          0          0
   TIMER:     253294     231092     218274     215528
  NET_TX:          6        279       8352       2104
  NET_RX:         54      14545      13852       4769
   BLOCK:       4791      32523       1668      30211
BLOCK_IOPOLL:          0          0          0          0
 TASKLET:      25567          7      23443          5
   SCHED:      99858      77539      71991      77167
 HRTIMER:        252        705        247        598
     RCU:     261007     236046     227241     231613

Nabyva jen counter na CPU3 a to jak RX tak TX.

Precetl jsem si ten link a dal jsem do smp F hexa a uz se rozklada eth0 na vsechny jadra.

Takze problem v ethernetu to nebyl nebot ksoftirqd nabyva stale az 30%

    4 root      20   0     0    0    0 S 14.6  0.0   4:26.18 ksoftirqd/0                             
    9 root      20   0     0    0    0 S 14.6  0.0   2:38.57 ksoftirqd/1 

Ted teda otazka co to dela ted kdyz sitovku uz se rozklada a nemela by tedy zatezovat CPU. CentOS 6.2 2.6.32-220.13.1.el6.x86_64 #1 SMP Tue Apr 17 23:56:34 BST 2012 x86_64 x86_64 x86_64 GNU/Linux

[michich]

Není vůbec jisté, že by rozkládání jednoho IRQ na více CPU mělo mít blahodárný vliv. Spíše je pravděpodobný opak.

Pusť si perf top a snad to napoví, jakou činnost ksoftirqd provádí.

[ironman]

no moudrej z toho nejsem

 PerfTop:      36 irqs/sec  kernel:77.8%  exact:  0.0% [1000Hz cycles],  (all, 4 CPUs)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------                             

             samples  pcnt function             DSO
             _______ _____ ____________________ ___________________

              234.00 81.8% intel_idle           [kernel.kallsyms]  
               10.00  3.5% _IO_vfscanf_internal /lib64/libc-2.12.so
                5.00  1.7% __GI___strcmp_ssse3  /lib64/libc-2.12.so

[michich]

Pusť to na konkrétní PID ksoftirqd procesu, např. perf top -p 4

[ironman]

Tak dal sem perf top -p 13. V okamziku kdy top ukaze 19% na pidu 19 - ksoftirqd/2 ,tak v perf nic. Zadny zaznam. Jeste zkusim pridat parametr -v a nechat to bezet dele. Zatim je to zahada.

[ironman]

jetse doplnim deska na ktere to bezi Asus AT5IONT-I

[ewew]

Podľa mňa je problém v tom, že smp_affinity pracuje s šesťnástkovou sústavou.

Binárne vyjadrenie čísla 8 je 00001000.

[ironman]

Proto, jak jsem psal, jsem nastavil na 0xF (hexa) = 15 (dec) dle linku co mi kolega napsal. A jak jsem psal zacaly se pohybovat citace na vsech jadrech. Ale problem s vytizenim CPU procesy ksoftirqd/1 - ksoftirqd/4 stale pretrvava.

            Binary       Hex 
    CPU 0    0001         1 
    CPU 1    0010         2
    CPU 2    0100         4
  + CPU 3    1000         8
    -----------------------
    both     1111         f

 * citovano z http://www.cs.uwaterloo.ca/~brecht/servers/apic/SMP-affinity.txt

[ewew]

Máš odložené logy, keď si tam mal opensource ovladač a potom.

Ja na Debiane mám tú istu sieťovku a nemá problémy s vyťaženým. V akej sieti to máš pripojené, aké služby ti bežia, máš zapnuté ignorovanie ARP rámcov ?

[iron-man]

Tezko rict zda je to zpusobeno tou sitovkou. Ja jsem tak usoudil na zaklade toho, ze se citace preruseni na ostatnich jadrech nepohybovali. Ted je to poresene, ale vytizeni pretrvava. Treba to nema se sitovkou nic spolecneho. Logy mlci a to jak pred tim s modulem z kernelu tak i ted s modulem od realteku. Ignorovani arp ramcu mam vypnute. Pocitac je zapojenej v lokalni siti do 3Com full gigabit switche a slouzi jako HTPC. Takze to vytizeni se negativne projevuje pri prehravani HD filmu

sysctl -a | grep arp_ignore
net.ipv4.conf.all.arp_ignore = 0
net.ipv4.conf.default.arp_ignore = 0
net.ipv4.conf.lo.arp_ignore = 0
net.ipv4.conf.eth0.arp_ignore = 0

[ewew]

Skús si nainštalovať nástroje atop a iotop.

A skús dať kopirovať nejaký veľký súbor a pozoruj hodnoty s tých dvoch nástrojov. Prípadne sleduj počítadla prerušení.

Skontoluj si procesy, ktoré bežia na to PC.

[ironman]

Nic panove diky za snahu a napady. Bohuzel ani diagnosticke nastroje neprozradili, kde by mohl byt problem. Rozhodl jsem se tedy CentOS vyhodit a nehodit tam Fedoru. Preci jenom Fedora ma novejsi jadro atd. Doufam, ze pojede dobre. Nerad bych skoncil u M$.

[ironman]

Fedora opet ukazala svou silu - bezi to na ni krasne. Zadne vytezovani zminenymi procesy. Takze resenim je pouzit Fedoru.

[Kozzi]

Narazili jsme na to stejne a resenim byla aktualizace jadra, jednalo se o bug v centos, ktery uz se ale v novych verzich neobjevuje