Vyzna se tu nekdo v planovani v jadru linuxu?

[Fila]

Narazil jsem na problem, ktery zrejme vyzaduje celkem slusnou znalost chovani planovace v linuxu, kterou ja nemam . Zna-li nekdo odpoved, ma u me cokoladu nebo flasku -- dle osobni preference .

Jde o to -- vyvijim haptickou aplikaci simulujici interakci biomolekul. Vypada to asi tak, ze mam na n-procesorovem stroji n-1 procesu, ktere pocitaji sily mezi molekulami, a jeden master proces, ktery se sklada z threadu, ktery pocita sily (stejne jako slavove), threadu ktery posila data renderovacimu programu, threadu ktery prijima prikazy od renderovaciho programu, threadu ktery komunikuje s haptickym zarizenim a threadu ktery vytvori knihovna pro hapticke zarizeni (ten jej udrzuje v jakemsi "konzistentnim stavu" nez prijde prikaz menici sily ktere na nej pusobi). Vsechny tyto thready, krome toho co pocita sily mezi molekulami, temer nic nedelaji a vetsinu casu travi budto primo ve usleep(), nebo se alespon cyklicky vzdavaji vypocetniho casu pomoci sched_yield(). To je nutne u threadu majicich primou navaznost na hapticke zarizeni, protoze to potrebuje min. 1 000 updatu za vterinu a na to je i usleep() prilis pomaly (usleep(1) nespi zdaleka jen jednu mikrosekundu).

No a kde je problem? Na singleprocesorovem stroji nikde. Na multiprocesoru se ale zacnou dit veci (tim casteji, cim je vic CPU)... Vypocetni cas se totiz zacne pridelovat dosti podivnym zpusobem. Muze se napr. stat, ze obnovovaci frekvence haptickeho zarizeni spadne z 1kHz klidne na nejake 2Hz. Pritom se vsechny thready vehementne vzdavaji vypocetniho casu, takze by se mel kazdy z nich dostat k lizu.

Proc si myslim, ze je problem nekde hluboko v linuxu a ne v me aplikaci? Protoze kdyz aplikaci spoustim na n-1 procesorech, je vse OK, kdyz ji spoustim na n procesorech, nastane zcela nahodne jeden z techto pripadu:
- aplikace bezi ocekavane, tedy rychleji nez na n-1 procesorech
- aplikace bezi pomaleji nez na n-1 procesorech, ale spomaleni neni dramaticke (treba dvojnasobne, petinasobne...)
- aplikace bezi extremne pomalu (spomaleni je klidne 500-nasobne)

Pricemz zduraznuji, ze vubec nic nemenim, jen opakovane spoustim. Zda se tedy, ze si planovac nejakym neprijemnym zpusobem v momente kdy ma vic threadu nez procesoru a stejny pocet threadu jako je procesoru vetsinu casu hodne intenzivne pocita postavi priority tak, ze se ostatni thready skoro nedostanou ke slovu, respektive jim to muze trvat i desetiny sekundy.

Jeste jedno voditko -- mel jsem v jednom threadu omylem blokujici volani send() na UDP port. Jelikoz to viselo v systemovem volani, tak se periodicky telo teto funkce vzdavalo CPU casu, presto ale byl zmineny problem daleko vetsi. Cely system bezel extremne pomalu i bez haptickeho zarizeni (bral jen fake data), zrejme se sukovala MPI komunikace (tu sprostredkovava daemon -- asi se tez nedostaval k casu). Cely system mel tendenci bezet napr. minutu extremne pomalu, pak najednou zrychlit (zase klidne tisicinasobne) a pak zase spomalit, nekdy bezel porad pomalu, nekdy porad rychle. Opet pri alokaci n-1 procesoru zadny problem.

Vypada to tedy, ze i kdyz se thready samy vzdavaji vypocetniho casu, planovac nedokaze v pripade, ze mame stejny pocet narocnych threadu jako CPU, spoustet mene narocne thready s dostatecnou frekvenci. Jedine reseni, co me zde napada, je udelat extra proces pracujici s haptickym zarizenim a ten spoustet s realtime planovanim -- to je ale neprijemne z toho hlediska, ze jej muze spustit jen root.

Ma-li kdokoliv napad k reseni ci vysvetleni, proc se system chova tak jak se chova, budu rad .

Ps. studenti FI kteri najdou stejnou otazku na foru v ISu necht me prosim nekamenuji -- je to natolik specificke tema, ze jsem povazoval za rozumne zeptat se na dvou mistech...

[Ladis]

Jen uvazuju - podle me je problem v tom, ze se thready opakovane vzdavaji vypocetniho casu. Planovac je pak asi nesmyslne prehazuje mezi procesory. Priklad: thread1 usne, thread2 usne, thread3 usne -> planovac je prehodi na stejny CPU/jadro, protoze nejaka systemova low priority vec v tu chvili vytezuje system vic nez tyhle 3 thready dohromady (malo je vic nez nic - muze to byt cokoli v pozadi, co se v tu chvili prihlasi o slovo). Pak se ty 3 thready probudi a vytezuji chvilku na 100 % (nez zas usnou) -> planovac je rozhodi na volne CPU.

Jenze premistovani procesu mezi CPU je dost pomale, prakticky je to okamzite vymazani vsech dat procesu ve vsech urovnich CPU cache, ktere nejsou sdilene mezi CPU (u modernich vicejadrovych procesoru muzou byt nektere urovne cache sdilene nebo rychle propojene, u samostatnych CPU sdilene samozrejme neni), a natahani do CPU cache noveho CPU.

Overit se to da tim, ze se procesory nebudou vzdavat CPU (cekat budou cyklem), pak budou vsechny furt vytezovat, takze je planovac rozhodi na vsechna CPU a nehybe s nimi.

Ve Windows se da treba myslim proces uzamknout na nejakem CPU, ale nevim, jestli se to da aplikacne udelat i per thread.

[rezna]

per thread je to SetThreadAfinity

[Mem]

Jj, to by mohlo být ono, např. v SQL Serveru 2005 se dá afinita nastavit a parametrizovat a jsou kolem toho dost důrazná varování, že to může s výkonem zamávat
_________________

[Tringi]

Pokaždé, když jsem se setkal s podobným náhodným chováním, tak se jednalo o chybu v mém programu. V žádném případě ne zjevnou, obvykle toto způsoboval nějaký fígl, který se projevil až právě na fyzicky dvou a více jádrech. Např. dvoufázové uzamykání (nebo jak se přesně tomu idiomu nadává). Dokonce jsem o tom vygooglil i článek s vysvětlením, ale nezapamatoval jsem si ho ...jen si pamatuju že se dá narazit na desítky různých takovýchle problémů, takže možná že jsi narazil na jeden z nich.

Asi bych hned neobviňoval plánovač ...třeba ten nevyužitý procesor o kterém píšeš má na práci něco jiného (přerušení) a tím že jej použiješ se to rozhodí. Každopádně používat nějaké yieldy na taktování je prasárna, minimálně na windows to může vytížit procesory na 100% s tím že tohle vytížení se ve většině indikátorů neukáže, protože se většina času tráví v režimu jádra (opět popisuju jen jak to je na Windows).

Trochu jsme s kolegy o tom diskutovali a další věc, která s tím možná souvisí je, že plánovač je uzamykán globálně (teda v aktuální verzi linuxového kernelu, v příští už to má být zase o něco lepší), tedy skoky do plánovače (yieldy) se serializují napříč všemi procesory.

Já bych vývoj směřoval k nahrazení těch yieldů za nějaký kvalitnější mechanizmus. Na Windows bych pomocí timeBeginPeriod zvýšil "kadenci" plánovače, a vlákna spouštěl z toho centrálního pomocí SetWaitableTimer (a funkcí kolem něj). Předpokládám, že linuxový plánovač bude mít alternativu k těmto.

[Fila]

[Fila]

[Tringi]

[Fila]

Dobre, ale to by zpusobovalo zasekavani vypoctu na max. 4ms, po kterych se spousti planovac -- pri neprijemne desynchronizaci by tak slo do kelu 50 % vykonu ostatnich CPU -- coz porad nevysvetluje spomaleni v radu stovek az tisicu.

[Tringi]

Možná. Nevím jak dále bys měl pokračovat ...jak jsem psal, já bych zkusil nahradit ten taktovací systém nějakým jiným, ale prostředky jádra Linuxu neznám. Pokud nemá ten tvůj projekt jinou závislost na Linuxu, zkus to pod Windows (jak přes yield, tak za pomocí waitable timerů) a uvidíš

[Fila]

Ted jsem jeste delal pokus -- postupne jsem nahazoval procesy zerouci nezrizene cas (yes > /dev/null) a po nekolikatem se stalo, ze jeden z procesu meho programu se nedostal temer vubec k CPU (ostatni jely na 100 % nebo treba 50 % protoze se delily o CPU s jednim yes > /dev/null) a ten jeden se nedostal ani k 1 % CPU -- vykon tim sel samozrejme kompletne do prdele.

Normalne bych to cele resil pres futexy, ale tady tim muzu umravnit thready hlavniho procesu, ostatni v principu nemuzu, protoze komunikuju pres MPI a nemam zadne sdilene prostredky.

Napadlo me ale jedno snad-reseni -- slavovske procesy volaji blokujici MPI operace, coz v principu nevadi, protoze ty lezou do jadra a tim umozni planovaci prepnout na jiny proces, nicmene je mozne, ze se mu zdaji prilis aktivni, takze prepina na ne a nedostane se na thready ovladajici hapticke zarizeni. Pokud je prepisu tak, ze zavolaji neblokujici MPI operaci a pak budou cyklit nad sched_yield(), je dost dobre mozne, ze se problemu zbavim, jelikoz si vynutim jejich zarazeni na konec planovane fronty.

[Crusty]

zde http://tldp.org/LDP/tlk/tlk.html v sekci 4.3.1 Scheduling in Multiprocessor Systems mozna neco uzitecneho najdes.

pak jsem jeste nasel toto http://www.ibm.com/developerworks/linux/library/l-scheduler/
_________________
http://www.2ox.cz

[Fila]

Kdyz jsme dali vlaknu ktere ovsluhuje hapticke zarizeni RT prioritu, tak to zaclo fungovat, takze se reseni uz i rysuje .
Krom toho si myslim ze tam mam vec kterou casovac uplne nezvlada a jeste ji muzu poopravit, aby se to nesukovalo i v momente, kdyz se nekdo rozhodne docasne vyzrat nejaky procesor.