Re: dziwne nowe klawiatury

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

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

> To koszmar. Nie jestem specjalistą w kwestii jądra Linuksa,
> ale wydawało mi się, że inaczej to wygląda.

Poprawię się nieco, bo chyba nie do końca dobrze powiedziałem. Pisałeś:

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

Otóż... - nie wiem. Nigdy nie dopuszczałem do takich sytuacji, a teraz
wszędzie mam IO APIC, więc nawet nie mam gdzie sprawdzić.

Natomiast z pewnością mając 2 karty na jednym IRQ, pozbawiasz się
możliwości wyboru konkretnego rdzenia do obsługi hard+softIRQ z
konkretnej KARTY. A taka wersja jest tą najoptymalniejszą (co zresztą
potwierdza przytoczony dokument Intela).

I to miałem na myśli - mając dwa przerwania mogę sztywno rozpisać je na
2 rdzenie, natomiast gdy 1 przerwanie obsługujące 2 karty ograniczę do
jedengo konkretnego rdzenia, to dostanie 100%; w takiej sytuacji trzeba
ustawić szerszą maskę procesorów (żeby dopuścić kolejne rdzenie) i...
zdać się na system, jak to rozłoży. Ot serwer, który dziś uruchomiłem:
- nie ma IRQ balance
- cat /proc/irq/{169,193}/smp_affinity
3
3
- grep -E '(169|193)' /proc/interrupts
169: 17743 75016425 IO-APIC-level eth0
193: 71489011 0 PCI-MSI eth1

Przerwania się rozłożyły tak a nie inaczej - gdybym jeszcze miał eth2
(tzn. mam eth2, eth3 cpu#2 i cpu#3, ale dopiero w poniedziałek
uruchamiam) to GDZIEŚ by trafiły. Włączając na poziomie kernela
IRQBALANCE system starałby się dodatkowo rozdzielać tymi przerwaniami po
równo, a z demonem irqbalance w userspace zmieniałoby się smp_affinity.
Gdyby to było na PIII, przerwania mogłyby iść na zmianę.

Twoje pytanie (jeśli dobrze rozumiem) dotyczy sytuacji, w której
przerwanie obsługujące dwa urządzenia NIE JEST ograniczane do
konkretnych rdzeni; wówczas jeden procesor przyjmie hardIRQ, natomiast z
procedurą obsługi co się stanie, jak już wspomniałem, nie wiem. Tego się
po prostu nie praktykuje.

> W Windows sytuacja wygląda następująco:
[...]

To się chyba nie różni od Linuksowego kernela... Dopiero tutaj:

> 5. Jeżeli kolejka procedur asynchronicznych jest niepusta,
> jest opróżniana. W tym momencie - w kwancie czasu procesu
> użytkownika (ale na podwyższonym IRQL i w trybie jądra),
> na dowolnym wolnym procesorze - kończona jest obsługa

Jak wybierany jest 'dowolny wolny'? Mając sytuację:

#0 95%
#1 5%
#2 5%
#3 5%

softIRQ trafi rozumiem na #0?

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

> Ale tu nie chodzi o samo zgłaszanie przerwań. Tu chodzi o
> implementację obsługi przerwań. W gorszym rozwiązaniu będzie
> się je obsługiwało na procesorze, który odebrał przerwanie.
> W lepszym -- na dowolnym wolnym procesorze, angażując ten
> odbierający ino na krótki moment.

Wróćmy do smp_affinity - tam się wpisuje maskę procesorów. Jak wpiszę
na każdej linii przerwania 1111 (binarnie), to chyba będę miał to lepsze
rozwiązanie - tyle że w praktyce jest gorsze:) Praktyczniejsze okazuje
się 'uwięzienie' tych procedur na konkretnych rdzeniach, co wiąże się z:

a) optymalizacją obciążenia poszczególnych jednostek, a co za tym idzie
lepszą responsywnością (choć wydajność spadnie: 35% na jednym rdzeniu
przełoży się na 4*10%, ale już jeden rdzeń nie poradziłby sobie z 4x40%).

b) płynniejszym wykorzystaniem cache.

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