Forum Debian Users Gang

zielkam · 2010-04-07 22:06:32

Hej,

Mam problem z jak w temacie. Ogólnie mam sobie sprzęt 2 Opterony każdy po 6 corów. Do systemu tego generuje dużą liczbę pakietów UDP, przy pewnej ilość ruchu sieciowego system zaczyna dziwnie się zachowywać. Z /proc/interrupts wynika, że wszystkie przerwania z interesującego mnie eth lecą do jednego core, zajęty jest on na 100% i przestaje przyjmować kolejne pakiety. Żaden z pozostałych 11 core nie zajmuje się obsługą tych przerwań. Testuje już ten system od kilku dni i nie potrafię dojść do tego dlaczego tak się dzieje. Poniżej bardziej szczegółowe dane.

Kod:

lspci 

00:01.0 PCI bridge: Broadcom BCM5785 [HT1000] PCI/PCI-X Bridge
00:02.0 Host bridge: Broadcom BCM5785 [HT1000] Legacy South Bridge
00:02.2 ISA bridge: Broadcom BCM5785 [HT1000] LPC
00:03.0 USB Controller: Broadcom BCM5785 [HT1000] USB (rev 01)
00:03.1 USB Controller: Broadcom BCM5785 [HT1000] USB (rev 01)
00:03.2 USB Controller: Broadcom BCM5785 [HT1000] USB (rev 01)
00:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
00:07.0 PCI bridge: Broadcom HT2100 PCI-Express Bridge (rev a2)
00:08.0 PCI bridge: Broadcom HT2100 PCI-Express Bridge (rev a2)
00:09.0 PCI bridge: Broadcom HT2100 PCI-Express Bridge (rev a2)
00:0a.0 PCI bridge: Broadcom HT2100 PCI-Express Bridge (rev a2)
00:0b.0 PCI bridge: Broadcom HT2100 PCI-Express Bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control
00:19.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control
01:00.0 PCI bridge: PLX Technology, Inc. PEX 8518 16-lane, 5-port PCI Express Switch (rev ac)
02:01.0 PCI bridge: PLX Technology, Inc. PEX 8518 16-lane, 5-port PCI Express Switch (rev ac)
02:02.0 PCI bridge: PLX Technology, Inc. PEX 8518 16-lane, 5-port PCI Express Switch (rev ac)
02:03.0 PCI bridge: PLX Technology, Inc. PEX 8518 16-lane, 5-port PCI Express Switch (rev ac)
03:00.0 PCI bridge: Broadcom EPB PCI-Express to PCI-X Bridge (rev c3)
04:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)
05:00.0 PCI bridge: Broadcom EPB PCI-Express to PCI-X Bridge (rev c3)
06:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)
07:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)
08:0d.0 PCI bridge: Broadcom BCM5785 [HT1000] PCI/PCI-X Bridge (rev c0)
08:0e.0 RAID bus controller: Broadcom BCM5785 [HT1000] SATA (Native SATA Mode)
0b:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)
0b:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

Kod:

cat /proc/interrupts

214:          0          0          0          0          0         14          0     232655   PCI-MSI-edge      eth2

Kod:

processor       : 7
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 8
model name      : Six-Core AMD Opteron(tm) Processor 2427
stepping        : 0
cpu MHz         : 2194.659
cache size      : 512 KB
physical id     : 1
siblings        : 4
core id         : 3
cpu cores       : 4
apicid          : 11
initial apicid  : 11
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt
bogomips        : 4389.06
clflush size    : 64
power management: ts ttp tm stc 100mhzsteps hwpstate

andreq · 2010-04-07 22:23:42

Jest taki pakiet irqbalance, który ma służyć do rozdzielania przerwań w systemach wieloprocesorowych. Z tego co dawnooo czytałem jego działanie w dużym stopniu zależało od płyty głównej - na jednych działało na drugich nie.

rychu · 2010-04-07 23:13:47

jak napisales o irq balancing to mi się wspomniało, że były jakies takie opcje w konfigu jajka. zielony, może coś nie wkompilowałeś?

zielkam · 2010-04-07 23:17:45

Hej,

Dzięki za odpowiedź, ale IRQbalance ma zajmować się rozdzielaniem przerwań w zależności od tego co chce się osiągnąć. Można "oszczędzać" procesory a przy tym energię, albo osiągnąć jak największą wydajność. Wszystko to daemon ten robi "bawiąc" się smp_affinity dla danego przerwania (po analizie kodu irqbalance). Defaultowo ustawia on na oczekiwaną przeze mnie wartość tzn używaj wszystkich procków, żeby osiągnąć jak największą wydajność, z tym że system (kernel?) nie potrafi przekazywać przerwań z tego urządzenia do wszystkich procesorów. Wydaje mi się, że problem jest w MSI dla tego układu eth. Chyba temat muszę wrzucić na lkml, albo spróbuję na innych NIC.

Pozdrawiam,

EDIT..

W sumie jajko kompilowane już po raz chyba 100, ciągle nie mogą z systemu wyciągnąć tyle ile trzeba, nawet nie mam pojęcia gdzie robię błąd. Z tego co mi się wydaje, to chyba żadna z kart PCI nie potrafi gadać do więcej niż 1 cpu. Fajnie mieć 12corówą maszynkę, na której wykorzystuje się jeden procek :(. Po trzech dniach stwierdzam, że może sprzęt tego nie umie zrobić. Dzięki za rady, szukam dalej.

EDIT 2.

Koniec końców poszliśmy inną ścieżką. Całe szczęście, że mieliśmy ethernety supportujące MSI-X. Pozwoliło to statycznie kierować zdarzenia z poszczególnych przerwań na oddzielne procesory. Nie jest to najlepsza metoda, ale rozwiązuje problem.

Dla zainteresowanych:

1.) Odradzam stanowczo stawianie linuksa na urządzeniach wyposażonych w procesory Opteron w połączeniu z płytą główną jak w powyższym lspci. Niestety do kernel 2.6.34-rc3 włącznie nie jest supportowane sensowne IO-APIC dla tego sprzętu, może to generować problemy w maszynach np zajmujących się routingiem sieciowym, przetwarzającym dużą ilość pakietów. W moim przypadku przy 12 corach udaje się przetwarzać około 500MBit/s, co obciąża maszynkę w jakiś 60%. Środowisko testowe generowało głównie ruch UDP. W przypadku tej konfiguracji musimy statycznie rozdzielać przerwania per cory. W przypadku urządzeń nie mających supportu do MSI-X niestety nie ma czym porządzić i nie pociągnie to za dużo.
2.)Ogólnie z poszukiwań jakie prowadziłem wynika, że niestety IO-APIC w kernelu potrafi obsłużyć do 8 corów na jednego etherneta. Z wyczytanych informacji wynika też, że w miarę sensownie zachowują się płyty z Intel Xeonami na pokładzie. Niestety potwierdzić tego nie potrafię na tak dużym sprzęcie, ale chętnie dowiem się jeśli ktoś ma podobny sprzęt. Wystarczy looknąć w /proc/interrupts i sprawdzić jak zmienia się stan np dla karty ethernetowej na poszczególnych corach.

To byłoby na tyle.

Pozdrawiam

Ostatnio edytowany przez zielony_83 (2010-04-09 23:27:26)

wujek · 2010-05-03 00:44:02

zielony_83 napisał(-a):
2.)Ogólnie z poszukiwań jakie prowadziłem wynika, że niestety IO-APIC w kernelu potrafi obsłużyć do 8 corów na jednego etherneta. Z wyczytanych informacji wynika też, że w miarę sensownie zachowują się płyty z Intel Xeonami na pokładzie. Niestety potwierdzić tego nie potrafię na tak dużym sprzęcie, ale chętnie dowiem się jeśli ktoś ma podobny sprzęt. Wystarczy looknąć w /proc/interrupts i sprawdzić jak zmienia się stan np dla karty ethernetowej na poszczególnych corach.

Pozdrawiam

hi, informacyjnie

ProLiant DL380 G5
Intel(R) Xeon(R) CPU X5450 @ 3.00GHz

Kod:

28: 2540568606 2540204676 2540114969 2540857347 2540658534 2541724778 2541497594 2540746724   PCI-MSI-edge      eth2
 29: 2544242732 2543844284 2543683342 2544423324 2544307614 2545438396 2545210653 2544429222   PCI-MSI-edge      eth3
 30:   41415450   41907747   41083191   41233207   41233878   40282569   40504723   41139271   PCI-MSI-edge      eth0
 31:    3150838    3449157    4548605    2926013    3233675    1980553    2189176    3032917   PCI-MSI-edge      eth1

pięknie działa, wiec można kupować DL'ki :D

pzdr

zielkam · 2010-05-03 12:47:31

Jaka wersja kernela ?

Edytka

Z tego Co widzę to masz w nim intele, potwierdza to moje przypuszczenia, że problem jest na AMD :)

Pozdrawiam,

Ostatnio edytowany przez zielony_83 (2010-05-03 12:51:09)

Forum Debian Users Gang

Ogłoszenie

#1 2010-04-07 22:06:32

zielkam - były zielony_83 :)

Zajmowanie CPU przez przerwania systemowe

Kod:

Kod:

Kod:

#2 2010-04-07 22:23:42

andreq - Członek DUG

Re: Zajmowanie CPU przez przerwania systemowe

#3 2010-04-07 23:13:47

rychu - elektryk dyżurny

Re: Zajmowanie CPU przez przerwania systemowe

#4 2010-04-07 23:17:45

zielkam - były zielony_83 :)

Re: Zajmowanie CPU przez przerwania systemowe

#5 2010-05-03 00:44:02

wujek - Nowy użytkownik

Re: Zajmowanie CPU przez przerwania systemowe

zielony_83 napisał(-a):

Kod:

#6 2010-05-03 12:47:31

zielkam - były zielony_83 :)

Re: Zajmowanie CPU przez przerwania systemowe

Stopka forum