loadavg na SMP

[Pavel Kankovsky]

On 23 May 2002, Cejka Rudolf wrote:

> Martin Zidek <arasidek na yahoo.com> wrote:
> > TASK_INTERRUPTIBLE se vyskytuje VELMI zridka, je to stav pri kterem

To, co pan Zidek napsal, byl pomerne velky ulet. Jednak tam mel v obou
moznostech napsano TASK_INTERRUPTIBLE, jednak to byl docela blabol, i
kdyz si clovek zkusil do jedne z variant dosadit TASK_*UN*INTERRUPTIBLE.

Co se tyce vyskytu uninterruptible sleep: ten nastava (na Linuxu)
v pripade, ze se 1. ceka behem provadeni operace, kterou z principu nelze
prerusit (napr. to hardware neumoznuje), 2. ceka na operaci, u ktere
lze ocekavat brzke dokonceni, a tudiz by bylo ztratou casu se snazit
naprogramovat to tak, aby bylo mozno osetrit preruseni teto operace
(napr. diskove operace; specialne u nekterych operaci nad fs by se navic
musel udelat rollback uz provedenych zmen, takze by preruseni nakonec
casto mohlo vyzadovat vic prace nez dokonceni).

> Kdo ma kratkou pamet, tak se jednalo minimalne o SCSI subsystem (load
> avg = 1 pri mt erase a podobnych operacich bylo/je skutecne komicke)

Komicke to na prvni pohled je. Pri hlubsim pohledu to uz tak absolutne
absurdni neni, protoze dokud bezi "mt erase", tak si nikdo jiny s paskou
ani neskrtne, cili nejmene jedna soucast celeho systemu je opravdu na
100 % vytizena. (Tim ale nijak neobhajuju to, ze mt erase je na Linuxu
neprerusitelne...i kdyz co vim, tak treba na Solarisu byl taky celkem
problem takovou operaci prerusit.)

> Jinde (zatim mi nikdo nenapsal, zda nekdo vi o systemu, ktery by
> load avg pocital jako Linux) je skutecne zvykem, ze se do load avg
> pocita jen run queue. Dokonce i dokumentace v Linuxu nic jineho
> nerika(la?).

Dokumentace je irelevantni. :)

Ovsem kdyz budu hodne velky sofista, tak muzu prohlasit, ze proces
cekajici na dokonceni diskove operace je vlastne pripraveny bezet a je jen
chyba neschopneho a pomaleho OS a HW, ze ho zdrzuji (kdo jim za to muze,
ze nemaji dost inteligentni prefetch, aby ta data byla uz davno pripravena
v RAM? -- v pripade cteni), takze je jedine rozumne ho do "run queue"
pocitat.


On 23 May 2002, Cejka Rudolf wrote:

> Hadat se o tom nebudu, ale jen pripomenu, ze tento pristup nasledne
> znamena, ze uzivatele pak opravdu mohou pozorovat load avg >= 100, a
> presto mohou na pocitaci pracovat jako kdyby moc zatizeny nebyl.

Kdyz se tam bude pocitat jen zatez CPU a budou spoustet jen programy, co
maji naroky na CPU takove, ze by je zvladlo i IQ-151, tak to muze
dopadnout stejne.

> (A abysme se netocili v kolecku, tak na tento argument jsem dostal
> dalsi hezke vysvetleni, ze vlastne load avg znamena, ze proste neco
> v systemu nestiha a na run-queue se pak uz zapomnelo.)

Neco podobneho jsem (i kdyz si nejsem jisty tim koncem o run-queue)
prohlasoval ja. Zatez systemu je prinejmensim vektor skladajici se ze
zateze CPU, disku, site...atd. a jakakoli jeho transformace na jediny
skalar musi vypadat za nekterych situaci absurdne.

No a ze vsech tech spatnych moznosti mi linuxovy pristup (ktery je
vicemene sumou polozek uvedeneho vektoru) pripada celkove uzitecnejsi,
nez ten "klasicky" (vybereme si jen jednu polozku: CPU) -- co je mi
platne, ze se muzu kochat lavg nula nula nic, protoze CPU porad stoji,
kdyz se mi muze zavarit disk?


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."