Re: dziwne nowe klawiatury

Radosław Sokół <Radoslaw.Sokol@polsl.pl> wrote:

>> 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

> No dobra, ale czy to się zmienia w momencie wrzucenia wszystkich
> kart sieciowych na jedno przerwanie?

Tak. Wtedy wszystko ląduje na jednym rdzeniu, który ma 100%, a pozostałe
nie są w ogóle używane i świecą zerami.

> Bo jeżeli system jest w
> stanie rozdzielać opóźnioną obsługę przerwań między rdzenie, to
> nie widzę problemu.

Nie jest. Będzie jak uruchomię IRQ balance w kernelu, ale wydajnościowo
jest to katastrofa.

>> 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.

> Przerzucać -- OK. Ale czy domyślnie wybierany jest wolny
> rdzeń?

Tak jak napisałem u góry - bez ustawienia affinity miałbym 100% na CPU#0
i totalny zator w sieci.

> Żeby nie wyszło, że to rozwiązanie jest gorsze niż
> rozwiązanie z NT z 1993 roku, gdzie już opóźnione przetwa-
> rzanie przerwania lądowało na pierwszym wolnym procesorze.

Nie wiem jak miał NT, ale przejmowanie obsługi przerwania na zmianę
przez procesory było zaimplementowane sprzętowo bodajże w PIII. Od tego
czasu jest to po prostu gorzej zrobione na poziomie hardware.

>> 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.

> Trzeba by właśnie zbadać pod obciążeniem dużym, bo ładowanie
> na jeden rdzeń może być optymalizacją -- cały kod i część

Teoretycznie. Praktycznie taka 'optymalizacja' powoduje, że zaczynają
dzwonić telefony, gdyż kolejne rdzenie włączane są w momencie
zablokowania pierwszego, a to się wiąże ze zmianami kontekstów itp.
stratami bardzo dużej liczby cykli.
I bardzo łatwo można zaobserwować efekty takiego przełączania -
wystarczy że zmienię podczas pracy rdzeń odpowiadający za obsługę
przerwania, aby bardzo wyraźnie (organoleptycznie) zauważyć krótkie
'zawachanie' systemu. Trwa to w granicach 0,5 sekundy, ale nietrudno
sobie wyobrazić co się stanie, gdy taka zmiana będzie następowała co 5
sekund. Ot czkawka.

> danych będzie już w cache właśnie tego rdzenia.

A jak mam obsługę na 4 rdzeniach, to przecież ten sam kod i ODPOWIEDNIE
dane (tzn. z tej samej sieciówki, a nie przenoszone potrzebą chwili z
drugiej, która już nie może być obsłużona pierwotnym rdzeniem) są
również w cache.

A powiem więcej - nawet da się określić, które sieciówki powinny być
razem w obrębie jednej dwurdzeniowej jednostki:)

Znalazłem nawet niedawno dokument dotyczący dokładnie tego, o czym
piszę: http://download.intel.com/design/chipsets/applnots/31433702.pdf

Wszystko powyższe to jest ...po prostu wieloletnia praktyka. Każdy kto
napotka problem wydajności procedur obsługi przerwań w końcu trafia na
smp_affinity i sztywne ich 'osadzenie' na rdzeniach. A że zwykle takie
obciążenie powodują routery (nawet nie wiem, jak inaczej można
wygenerować 20ksIRQ/s), to mało kto poza sieciowcami widuje to w
praktyce.

-- 
Tomek                                    http://tccs.sourceforge.net/
http://pld-linux.org/                    http://vfmg.sourceforge.net/