Administrace komentářů

Pokud proces visi na diskovym io tak se to nepocita jako jeho cas. Pokud ale stihne zatopit dost na to aby kernel stravil vetsinu casu cekanim az se protoci nejakej spinlock tak je masina na plech a cas straveny v ring0 bude ve statistice chybet. Chytrejsi widgety na sledovani to i umi ukazat ("prohlizec zateze systemu" ukazuje zvlast userspace, kernel a io cas), ale i na hloupejsim to poznas protoze se to zacne chovat jak popisujes: mas zatez ktera odpovida 100% zatezi jednoho jadra a nechce se hnout. Pokud je to jeden proces tak se zalomi na jednom jadre, kdyz jich bude vic tak obcas preskoci ale porad to bude dohromady davat 100%.

Pokud te netrapi cas, docela hodne v takovym pripade pomuze snizit prioritu diskoveho planovace na idle. Kernel pak nebude ztracet cas tocenim spinlocku a takovou ulohu rovnou odlozi na "az nebude do ceho pichnout". Cili to bude trvat vyrazne dele (staci pustit browser ktery tu a tam ukapne par bajtu do svoji cache a kernel uz to bere ze je do ceho pichnout) ale masina uz se nechova jak v poslednim tazeni.

BTW v podstate soudruzi udelali chybu v tom ze kdyz dostanou moc prace tak se snazi udelat vsechnu najednou. Vetsinou je to tak dobre protoze se tak zabrani prostojum a vyzdimes vic prace za jednotku casu.

Pak je tu jeste jedna znepokojivejsi moznost – muze se to takhle chovat taky proto ze disk je pred zdechnutim. Zacne travit vetsinu casu relokaci vadnych sektoru nebo nejakou takovou ptakovinou a s tim kernelovej io planovac nic nenadela.