Albo ustawiając smp_affinity dla danego IRQ.

@trasz: o widzisz, dwi godziny pozniej piszesz, ze jednak dalo sie to robic w Linuksie duzo wczesniej… Fajnie, jakbys jeszcze rozumial idee irqbalance.

Tak jak piszesz, interrupt threads nie ma nic do pakietow out-of-order, ani z przetwarzaniem pakietow aplikacji na tym samym procesorze – dziekuje, ze uznales tym samym wyzszosc Linuksa.

@gotar i mangoo: a może mały artykulik o tych rozwiązaniach i porównanie do 'innych uniksowatych'.

@trasz: "wazne, ze nie dzialo sie to automatycznie"

Ależ działo – smp_affinity właśnie służy do _ograniczania_ owej automatyki w sytuacji, w której administrator lepiej wie, jak co MA działać (np. nie chce, aby obciążenie z DDoS 'rozłożyło' się na wszystkie rdzenie uniemożliwiając zalogowanie się do maszyny).

"automatycznie – w koncu watek to watek – a w Linuksie trzeba kombinowac, albo, jak wczesniej, recznie, albo uzywajac kolejnego workarounda."

Chyba nie do końca wiesz, o czym piszesz – wektor przerwań (jeden wątek) domyślnie obsługiwany w round-robin na kolejnych rdzeniach (na odpowiednim sprzęcie, nie wszędzie to działa, w szczególności broadcasty są wyłączane przy dużej liczbie rdzeni) ograniczało się poprzez affinity tylko do wybranych. O ile w ten sposób wykorzystujemy więcej rdzeni, o tyle uwalamy cache coherence. Rozwiązaniem na to są karty wielokolejkowe (MSI-X), które używają hashowania kilku wartości z ramek w celu przypisania jednego połączenia na stałe do jednej kolejki – a przez to dalej do jeszcze węższej grupy rdzeni (idealnie: do jednego, gdy liczba kolejek RX==liczbie rdzeni, bo TX przy tym co ja np. robię nie ma żadnego znaczenia). RPS załatwia właśnie problem z cache na kartach 1-kolejkowych (ogólnie: mniej-niż-rdzenio-kolejkowych) oraz może ewentualnie takich, które nie obsługują hashowania. Zapewne pomoże to ludziom, którzy mając SMP używali NAPI (czy to z braku wiedzy, czy nieodpowiedniego sprzętu – choć zły zakup to też brak wiedzy). NIE SĄDZĘ, że pozwoli na rozłożenie SoftIRQ na sprzęcie, na którym do tej pory to nie działało; rozumiem że twierdzisz, iż w innych systemach działało to wszędzie!? Bardzo jestem ciekaw, bo mi się wydawało, iż problemem jest APIC, czyli sprzęt. Niezbyt sobie wyobrażam programowe obejście QuickPath kierującego w physical mode bez x2APIC przerwanie do konkretnego procesora – w tej łacie nie widzę przeprogramowywania APIC z każdą ramką; ale nawet gdyby coś takiego było możliwe – czyżbyś więc uważał, że rozwiązanie klasy '1 procesor przyjmuje przerwanie i przekazuje jego obsługę do innego, bo sprzęt nie umie tego zrobić', uważał za killer-feature dobrego systemu? Bo mi się zawsze wydawało, że po prostu należy kupić właściwy sprzęt.

Mówiąc krótko: RPS (a tym bardziej RFS) to mechanizmy wspierające cache locality oraz aplikacje korzystające z sieci. Obie te rzeczy mają tyle wspólnego z irqbalance, o którym wspomniałeś …że dają dokładnie odwrotny efekt!

@Tomasz Woźniak – nie walczyłem z przetwarzaniem przerwań na innych unices, ale z informacji, jakie pobieżnie (zaznaczam) gdzieś mi się ujawniły, wynikało że FreeBSD ma to znacznie gorzej rozwiązane.

@trasz: "problem specyficzny dla jakiegos Linuksianego eksperymentu, ktory rozrzucal pakiety roundrobinem na kilka CPU. Jest to glupie, wiec inne systemy tego nie robia."

BUAHAHAHAHAHHAHHAAAAAAAAAAAAAAAAA

@trasz:

"Wiec twierdzisz, ze jakis system nie bedacy Linuksem ma watki przerwan bez CPU affinity. Ciekawe. Ktory konkretnie?"

Nie pisałem nic o żadnym innym systemie, więc musisz rozjaśnić skąd wyczytałeś takie moje rzekome twierdzenie.

"Odnosnie “przekazywania” przerwan miedzy kontrolerami – oj, cos mi swita, ze mocno nie rozumiesz tego mechanizmu. Przerwanie – w sensie, to zglaszane przez APIC – budzi watek i maskuje przerwanie. Nic wiecej nie robi. Nie obchodzi go, na ktorym procesorze watek sie wykona."

Heheheh… W logical destination mode – owszem. Niestety ten tryb dostarczania przerwań (a maską CPU) nie jest jedyny i jest niedostępny np. w x2APIC, bo wymagałoby to rozgłoszenia każdego przerwania każdym(!) obecnym linkiem p2p.

Musisz zaktualizować swoją wiedzę poza ostatnie parę lat, bo chyba zatrzymałeś się tak w okolicach FSB.
Ostatni sprawdzany przeze mnie Nehalem miał 2 układy APIC, 4 QuickPath i …jedno przerwanie==jeden rdzeń. To nie była zaleta.

"Znow – jestes pewien, ze nie mylisz normalnych interrupt threads z jakims Linuksianym eksperymentem, ktory byl po prostu strasznie kulawa implementacja?"

Nie. W trybie, o którym sam piszesz, przerwanie jest rozgłaszane do wszystkich CPU, a przejmuje je ten, który akurat ma najmniej do roboty (lowest priority delivery mode, co w przypadku obciążania jedynie jednostajnym ruchem sieciowym oznacza de facto round robin). Pisałeś, że to głupie, więc inne systemy tego nie robią – i w porządku, jeśli tego nie chcesz, to wyłączasz (smp_affinity ustawiane z ręki albo przez irqbalance, tj. demona userspace, nie myl z kernelowym irqbalace). Czyli ta przewaga innych systemów polega na tym, że nie pozwalają zrobić 'czegoś głupiego'? 😉

Tylko czekaj czekaj, wiesz co… "Pentium processor system architecture", rozdział 15, strona 365 – jakoś mi się dziwnie wydaje, że to nie jest żaden "strasznie kulawy linuksiany eksperyment", tylko zwyczajna funkcja SPRZĘTOWA. Czyli te "fajne systemy" po prostu jej nie obsługują (albo o tym nie wiesz) 🙂

A mi ona jest potrzebna…
Już wyjaśniałem, że wolę mieć 240% sumarycznego obciążenia niż 160%, ale z zapasem kolejnych 560% zamiast marnych 40%, jeśli wektorów przerwań mi po prostu brakuje w sprzęcie. Tylko ja do swojego Linuksa mogę włożyć kartę z 16 kolejkami RX/TX i mi to zadziała.

@trasz: jeszcze jedno

"Interrupt threads nic nie maja ani do pakietow out-of-order (skad to wziales w ogole?), ani z przetwarzaniem pakietow aplikacji na tym samym procesorze."

Dokładnie – zatem wskaż analogiczny mechanizm we FreeBSD.

"(Jestes pewien, ze rozumiesz, czym w ogole sa interrupt threads?)"

Ta rozmowa wygląda tak:
– Lubię cytryny, są tak genialnie kwaśne i wspaniale żółte.
– Moja kopareczka jest bardziej żółta!
– Ale jej sobie nie przegryziesz.
– Jesteś pewien, że rozumiesz, czym w ogóle jest koparka-zabawka!? Tego się nie je!

Fakt – o "interrupt threads" wspomniałeś już w pierwszym komentarzu. Tylko to było raczej nie na temat, więc "jak juz dojdziesz, do czego sluzy RPS i RFS" to powinieneś zrozumieć, że jest to zupełnie inna technika, niezależna od przerwań. Bo właśnie tymi swoimi przerwaniami nie dopasujesz pakietów do procesora, na którym wisi aplikacja je odbierająca.

Krótko mówiąc: przyjmij do wiadomości, że sensowne rozkładanie obciążenia między procesory to nie jest jakieś jedno proste hokus pokus, tylko cała gama komplementarnych metod. Aktualnie Linux ma zaimplementowane już wszystkie z nich – a ile ma FreeBSD?

@trasz: dużo ważniejsze od interrupt threads jest multiqueue – jeśli nie napisałem tego wyraźnie.
RPS/RPF jest mniej ważny – zgadzam się. W Linuksie zostało to zatem zaimplementowane we właściwej kolejności, FreeBSD natomiast do dzisiaj ma wyłącznie interrupt threads.

Co do 'losowego' (dokładnie lowest priority z RR przy jednakowym prio) rozrzucania, to jak już wspomniałem zostało to zaimplementowane w sprzęcie, więc niezależnie jaki to OS, kwestia jest wyłącznie zaprogramowania APIC-a.