Radosław Sokół <Radoslaw.Sokol@polsl.pl> wrote:
>> jednostką HT, co z kolei prowadzić może do przeciążenia danego rdzenia
>> (softIRQ) przy niewykorzystaniu drugiego.
> Tylko do samego przyjęcia przerwania. Obsługa leci już na
> *dowolnym* procesorze.
Czy przejście pakietu przez cały netfilter i kolejki jest obsługą? Bo mi
się wydaje, że jest. To teraz wyjaśnij mi kolumnę si (dla jasności od
razu mówię, że wyłączenie firewalla i kolejek powoduje znaczny spadek
właśnie TEJ kolumny, zresztą inne jak widać w ogóle nie pracują).
Cpu0 : 0.0% us, 0.0% sy, 0.0% ni, 84.0% id, 0.0% wa, 0.0% hi, 16.0% si
Cpu1 : 0.0% us, 0.0% sy, 0.0% ni, 76.0% id, 0.0% wa, 0.0% hi, 24.0% si
Cpu2 : 0.0% us, 0.0% sy, 0.0% ni, 72.0% id, 0.0% wa, 0.0% hi, 28.0% si
Cpu3 : 0.0% us, 0.0% sy, 0.0% ni, 64.0% id, 0.0% wa, 0.0% hi, 36.0% si
> W Linuksie (chodzi mi o najnowsze
> jądra 2.6) jest to, o ile się nie mylę, podobnie jak w
> Windows: procedura obsługi przerwania ma działać jak naj-
> krócej, odbierając tylko dane od urządzenia i zlecając
Tak - czas procesora spędzony na tej operacji widzisz w kolumnie hi.
Gdy karta dojdzie do wniosku (zależnie od paru parametrów, także
konfigurowalne), że przerwań jest zbyt wiele i traci czas na ich
wykonywanie, to może włączyć polling, zwany NAPI (nie wszystkie
obsługują). Żeby się nie powtarzać, zobacz Interrupt Mitigation
choćby tu http://www.fefe.de/linuxeth/ Widziałem już sytuacje, gdy na
pojedyńczych przerwaniach szedł przez kilkanaście sekund strumień danych.
15:58:38 CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
15:58:38 all 0.19 0.00 0.25 0.59 0.89 30.79 0.00 67.29 16837.11
15:58:38 0 0.15 0.00 0.23 0.07 0.59 28.77 0.00 70.19 631.09
15:58:38 1 0.26 0.00 0.22 0.07 0.47 30.12 0.00 68.85 4151.45
15:58:38 2 0.16 0.00 0.26 0.12 1.28 29.32 0.00 68.85 4152.09
15:58:38 3 0.20 0.01 0.27 2.08 1.20 34.96 0.00 61.29 4267.03
Jak widać - mam niecałe 17kIRQ/s, natomiast w tym momencie ruch wynosi
30kpps (symetrycznie oczywiście, co prawda nie są to ramki, ale raczej
nie spodziewałbym się, aby każda ramka niosła dwa pakiety).
> dalsze ich przetwarzanie asynchronicznej procedurze
> wykonywanej już na zupełnie dowolnym procesorze/rdzeniu.
No, wszystko się zgadza aż do momentu 'dowolnym' - to co widzisz akapit
wyżej, mogę dowolnie przerzucać sobie pomiędzy rdzeniami właśnie poprzez
smp_affinity.
> Zresztą domyślnie przerwania też chyba są przypisywanie
> na zmianę rdzeniom, więc system będzie sam równoważył
> obciążenie.
Domyślnie, tj. system SMP i brak IRQ balance, wszystkie trafiają w 1.
rdzeń. Może pod dużym obciążeniem przechodzą na kolejne, ale nie jest to
'na zmianę' - round robin działa dopiero po włączeniu IRQ balance w
kernelu.
>> Nie na pierwszym wolnym - właśnie o tym mówię. To IRQ balance w kernelu
>> stosuje politykę round-robin, ale softIRQ (procedury obsługi przerwania)
> AFAIK to jest starsza metoda, teraz obsługa leci już na
> zwykłych kolejkach "worker queue", uruchamianych w ramach
> zwykłych wątków jądra obsługiwanych standardowym schedu-
> lerem.
3 root 34 19 0 0 0 S 0 0.0 0:55.17 [ksoftirqd/0]
5 root 34 19 0 0 0 S 0 0.0 4:26.43 [ksoftirqd/1]
7 root 34 19 0 0 0 S 0 0.0 168:28.25 [ksoftirqd/2]
9 root 34 19 0 0 0 S 0 0.0 0:32.54 [ksoftirqd/3]
O tym mówisz? Serwer ma uptime 5 dni, obciążenie każdego rdzenia 20%,
czyli każdy z tych wątków powinien mieć wykorzystane jakieś 24 godziny
czasu procesora. Czym wyjaśnisz taką rozbieżność, czemu cały czas tych
wątków jest na CPU#2? Przecież obciążenie 'si' jak widzisz wyżej jest
cały czas rozłożone równomiernie.
> Owszem, rdzeń na którym przyjęto przerwanie może
> być preferowany ze względu na wydajność, ale niekoniecznie
> musi zostać wybrany.
W smp_affinity ustawia się maskę - jak wpiszę sobie tam 3, to działać
może na CPU#0 i #1, ale jak wpiszę 2, to nie wiem czy 'niekoniecznie'
musi na CPU#1 zostać obsłużone, ale z praktyki wynika, że prawie zawsze
BĘDZIE:
16: 331284878 5 172 79887 IO-APIC-level eth0
17: 0 3443737351 0 2 IO-APIC-level eth1
18: 3 5 2402891127 57620 IO-APIC-level eth2
19: 4684 849159 525710 2486805173 IO-APIC-level eth3
^^^^^^
Ta liczba rzeczywiście urosła w trakcie, gdy to piszę, ale dysproporcja
jest znacząca: to jest 0.02%.
-- Tomek http://tccs.sourceforge.net/ http://pld-linux.org/ http://vfmg.sourceforge.net/Received on Sun Apr 13 19:23:15 2008
To archiwum zostało wygenerowane przez hypermail 2.1.8 : Sun 13 Apr 2008 - 19:51:26 MET DST