loadavg na SMP

Stanislav Meduna stano-cznews na meduna.org
Neděle Květen 19 22:48:17 CEST 2002


On 19 May 2002 16:26:02 GMT, Cejka Rudolf wrote:

: A dyt je to tady stale dokolecka - clovek to muze opakovat kolikrat
: chce, ale stejne ho nikdo nevezme na vedomi - jsme v konferenci
: o Linuxu a tohle plati pro Linux jen castene. Na Linuxu je load
: average vetsi nebo roven "prumernemu" poctu uloh schopnych bezet
: v danem case.

Kym som odpovedal, pozrel som do kodu. Myslim si, ze moja odpoved
je pre realne mixy "dostatocne" dobra - patologicky pripad sa da
najst vzdy.

:> Moze kludne nastat situacia, kedy bude load average 1 a pocitac
:> nebude stihat plnit svoje ulohy a rovnako aj load average 10,
:> ked to stihat bude.

: V Linuxu je to docela realne, ale jinde, kde se skutecne pocita
: velikost run queue, si to moc dobre predstavit nedokazu - mam-li
: na takovem systemu s 1 procesorem load 10, pak procesor proste
: nestiha a tecka.

Popisem, vysvetlim :-) Mam 10 pouzivatelov, ktori maju urcite
poziadavky - napr. ze ich dotaz na system bude aspon ciastocne
zodpovedany v case mensom ako x sekund. Napriklad ze dostanu
aspon text stranky a obrazky mozu dobublat neskor. Mozem ich
poziadavky serializovat a spracovat jednym serverom - budem mat
sice load average o chlp mensi ako jedna (lebo sa chvilu bude
cakat na siet), ale spokojny bude zrejme iba ten prvy vo fronte.
Mozem na kazdu forknut jeden server - spokojni budu vsetci.
Mozem ten scheduling medzi poziadavkami robit sam - dostanem
sice predchadzajuci pripad pri load-e 1, ale naprogramujem
sa ako kon (been there, done that :-)).

Niekedy ma zase uloha taky charakter, ze sa strieda vytazenie
CPU s cakanim na hardware. Typicky priklad: rychly procesor,
pomalsi disk, dlhsia kompilacia, load bude povedzme 0.9.
V takom pripade moze pomoct make -j2 - load bude sice vacsi,
ale budem mat istotu, ze kym jeden proces caka na disk,
procesor nezahala. V druhom pripade _budem_ skor hotovy -
znovu som to uz zazil aj na jednoprocesorovom stroji.

Mnozstvo operacii vykonatelnych za jednotku casu sa proste
nemeni. Akonahle som v oblasti nad 1, je uz v zasade jedno,
o kolko nad 1 (pochopitelne pokial nejde o extremy).
Pokial som v oblasti pod 1, este to neznamena, ze svojich
pouzivatelov nezdrzujem. Namiesto fronty v masine mozno
rastie fronta pred nou.

Teoria hromadnej obsluhy je vazna matematika, ktorou som sa
nastastie nikdy vaznejsie nezaoberal :-)

: Ale opet - v Linuxu to platit nemusi. Uz to tu bylo nekolikrat
: a asi stale zbytecne. Divam se do zdrojaku 2.5.16 a smycka, ktera
: load pocita, je stale stejna, takze nemam pocit, ze se to v Linuxu
: uz zmenilo - nebo mi neco unika?

:         for_each_task(p) {
:                 if ((p->state == TASK_RUNNING ||
:                      (p->state & TASK_UNINTERRUPTIBLE)))
:                         nr += FIXED_1;
:         }

Predpokladam, ze jednym z cielov vyvoja je mat percento procesov
v stave UNINTERRUPTIBLE co najmensie :-) Ale nie som jadrovy
specialista, to by mohol vysvetlit niekto iny.

Zdravi
-- 
                                     Stano



Další informace o konferenci Linux