Re: dziwne nowe klawiatury

Autor: Radosław Sokół <Radoslaw.Sokol_at_polsl.pl>
Data: Wed 28 Nov 2007 - 09:14:30 MET
Message-ID: <fij819$n58$1@polsl.pl>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed

gotar pisze:
> 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

No dobra, ale czy to się zmienia w momencie wrzucenia wszystkich
kart sieciowych na jedno przerwanie? Bo jeżeli system jest w
stanie rozdzielać opóźnioną obsługę przerwań między rdzenie, to
nie widzę problemu.

> 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ń? Ż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.

> 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ęść
danych będzie już w cache właśnie tego rdzenia.

-- 
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Administrator, Politechnika Śląska    |
\................... Microsoft MVP ......................../
Received on Wed Nov 28 09:15:07 2007

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Wed 28 Nov 2007 - 09:51:20 MET