jadro 2.4.x a vytizeni praci s diskem

[Míla Kuchta]

Zdravim,

Pavel Kankovsky <peak na argo.troja.mff.cuni.cz> wrote:
> Problem spociva v tom, co je to "spravedliva cast". Ted mam na svem PC

To mate svatou pravdu.

> spusteno asi 60 procesu. Cert vem CPU, to lze snadno a rychle preplanovat,
> ale znamena to, ze by kazdy proces mel mit k dispozici prave 1/60 volne
> kapacity RAM (jak pro stranky sve virtualni pameti, tak pro buffery
> souboru, se kterymi pracuje)? To je samozrejme blbost, nekteremu staci

O pameti jsem nemluvil.

> malo (specialne tem procesum, co porad spi), jini potrebuji mnohem vic (X
> server, I/O intenzivni procesy) -- a jadro by to melo zohlednit.

Pokud je proces zablokovan nad nejakou udalosti (spi), tak to asi
nebude vhodny kandidat pro beh:-).

Tady je trochu problem v tom, ze ty I/O intenzivni procesy
spotrebovavaji nemale mnozstvi casu a systemovych zdroju v rezimu
jadra (find, locate - namei; grep - bmap) a to presto, ze se volanim
jadra dobrovolne vzdavaji procesoru, muze za prispeni Vami nize
zminenych okolnosti zvrhnout v jaderny kanibalismus:-).

> Nicmene se zda (jak jsme o tom chvilku diskutovali s Kamilem Tomanem),
> ze kritizovana verze 2.4.x proste presla z jednoho extremu (kazdy stejnym
> dilem) do uplne opacneho (kdo je drzejsi, ten dostane nejvic). A navic se

Mate na mysli tu skutecnost, ze add_to_runqueue() pridava procesy na
zacatek seznamu?

IMHO, pokud je tomu tak (nectu lk), tak mi to prijde jako dost spatny
vtip. Interaktivni aplikace (aplikace co jsou casto zablokovany), by
naopak meli dostat vysokou prioritu, protoze je stejne pravdepodobne,
ze se za kratkou dobu zase zablokuji.

BTW, velice se mi libi zpusob planovani na Aegisu (exokernel). Tam si
procesy vyhrazuji cas CPU, na zpusob alokace fyzicke pameti, v
linearnim vektoru, jehoz kazdy prvek predstavuje casove kvantum.
Planovani pak probiha zpusobem round robin, kde se postupne prochazi
timto vektorem. Toto scheme nejenze umoznuje sofistikovany pristup k
procesum, ale dle meho nazoru musi byt i mnohem efektivnejsi a nemusi
tam tak casto dochazet k zbytecnym prodlevam. Napr. vypocetne
narocnejsi vedecke aplikace si vyhradi mene delsich spojitych useku,
aby minimalizovaly pocet prepnuti kontextu, naproti tomu interaktivni
aplikace naopak vice kratkych useku pro lepsi odezvy. To je ale
mechanismus na Unixech neresitelny, takze to radsi nebudu dale
rozebirat:-).

> asi nekde ztratilo pravidlo, ze nema smysl v kesi drzet bloky ze souboru
> atd., ke kterym se zjevne pristupuje sekvencne (a je tudiz malo
> pravdepodobne, ze ty uz jednou zpracovane budou v blizke budoucnosti
> opet zapotrebi).

Jde o to, jestli logika, ktera to zjistuje neni slozitejsi (a tedy
vypocetne narocnejsi) nez osvedceny mechanismus starnuti stranek.

S pozdravem

Mila Kuchta