rychlejsi/presnejsi casovac v kernelu u redhat 8?
Michal Dobes
dobes na tesnet.cz
Čtvrtek Září 26 13:09:59 CEST 2002
Petr Stehlik wrote:
> Funguje nekdo s timto upravenym kernelem? Zajimalo by me, proc zvolili
> 512 a ne 500 - jak to tedka nejak rozumne podeli? A chapu to dobre, ze
Predpoladam, ze to je dano nejakou delickou a vychazi to v ni na tech
512 Hz a nikoliv 500 Hz. Nechce se mi ted nad tim premyslet. :-)
Linux na alfach tusim pouziva 1024 Hz.
> se ted thready prepinaji casteji nez drive? Jak se vlastne casto u
> normalniho linuxu prepinaji thready/procesy - 100x za sekundu? Nebo mene
Ano, 100x za sekundu, je-li k tomu duvod. Obvykle v systemu ceka
spousta uloh na vyrizeni nejakych I/O pozadavku nebo udalost
a nejsou vubec spusteny. Pokud by bezelo vice bez blokovani na nejake
udalosti, tak se to bude menit max. tech 100 Hz, hraje do toho
samozrejme otazka priorit a pouziteho scheduleru.
> casto? Ja bych kazdopadne potreboval alespon 200x za sekundu, takze
> kdyby to u tohodle kernelu bylo 256 nebo 512, asi bych byl spokojen.
Nikde nemate absolutne nic receno, kdy se dostane vase uloha k lizu.
Unix neni real time OS, takze vase aplikace muze byt dle uvazeni
systemu klidne spustena jen jednou za hoooodne dlouho v zavislosti na
dalsich bezicich procesech. Normalni unix (i linux) abslutne toto
nezarucuje. Takze pokud vase aplikace na tech minimalne 200 Hz
kriticky zavisla, tak to muze jet dlouho OK, nez .... nekdo zacne
zurive delat neco jineho nebo pro vas necekaneho.
Trochu se to da poresit zmenou scheduleru za pomoci sched_setparam()
a pouzitim SCHED_FIFO nebo SCHED_RR, ale ani tak to neni zcela jiste.
S timto se budete pohybovat v prumeru v chybach desitek milisekund.
Dalsi bod je treba pamet, pokud bude uloha odswapovana, tak se casovani
opet nabori (resitelne treba pres mlockall()).
Dalsi bod do toho hrajici je pouzity HW. Muze se vam pri nevhodne
kombinaci stat, ze nektrere HW operace muzou narusit presnost
casovani. Zvlaste na IA32 platforme se da najit nektere slabe mista
(uplne staci blby IDE radic s blbou podporou a nejaky proces
presouvajici velke mnozstvi dat). Ale vykyvy HW vetsinou nepusobi
chyby vetsi nez pod 1 ms.
> Jen
> aby pak nezacalo padat neco jineho - prece jen je to asi pekne kruta
> zmena uvnitr kernelu.
Jde o to, zda RH prepsal vsedu vse s tim svazane. V nekterych jadrech
se vyskytovalo nekolik veci napsanych tak, ze netvrdo predpokladaji
100 Hz, coz muze byt problem.
Majkl
Další informace o konferenci Linux