loadavg na SMP

[Martin Zidek]

Prakticky TASK_UNINTERRUPTIBLE je podobny TASK_INTERRUPTIBLE.
S rozdilem ze
TASK_INTERRUPTIBLE - stav ve kterem je proces supended (sleeping), ceka 
na uvolneni HW, podminky, systemovy zdroj nebo signal... Klasicke cekani.

TASK_INTERRUPTIBLE se vyskytuje VELMI zridka, je to stav pri kterem
proces spi, ale nereaguje na signaly. Treba kdyz otevira soubor, ale
device driver neni pripraveny a potrebuje napr. detekovat hw. V takovem
pripdade by bylo nebezpecne takovy to proces v kernelu prerusit ( 
nemoznost ukoncit detekce hardware, chybna detekce ), proto se hodi 
tento stav.

Takze mily pane Cejko, tato struktura

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


	je prakticky


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


Ovsem jiste BSD to resi lip, urcite tim, ze pri inicializaci driveru 
maskuje pro jistotu vsechna presuseni, coz je sice jistota, ale urcite 
to odporuje dobre skalovatelnosti. Co jsem se na BSD dival, tak podpora 
SMP je VICE nez spatna.

S pozdravem

Martin Zidek

Stanislav Meduna wrote:
> 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