OK, svaki drajver moze da za*ere sistem zato sto drajveri obicno servisiraju interapte, rade DMA transfere i sl.
Ne znam za AMD drajvere, ali znam da mogu dovesti NVIDIA drajver do toga da bukvalno zaglavi ceo ostatak OS-a dok prenosi gigabajte geometrije na GPU. To nije nenormalno ponasanje, posto je ceo use-case takav da prakticno nema nekog boljeg resenja. Trazio si od drajvera da sibne neku kompresovanu geometriju velicine 16 GB i da onda izvrsi neku nenormalno dugu operaciju nad tom geometrijom koja graficku karticu blokira za sve drugo (graficke kartice za sada nemaju OS sa schedulerom koji prekida niti), drajver jednostavno radi ono sto si trazio od njega, GUI be damned.
Windows Server ima neki timeout posle koga ubije GPU drajver, zbog cega prvo moras to da ugasis ako planiras operacije koje ce blokirati ostatak OS-a na vise od nekoliko sekundi.
Ako se sistem ponasa nenormalno u rezimu gde ne bi trebalo da bude problema, uvek bih prvo proverio:
1. Procese, ukljucujuci i kernel mode zauzece procesora
2. Interapte (kolicinu, kao i latenciju odlozenih procedura)
3. Kolicinu context switch-eva
4. CPU C i T stanja, da slucajno power management ne baca CPU u LFM mod ili zbog nekog razloga se aktivira throttling (u kom slucaju treba pogledati temperaturu, itd.)
Obicno nesto od ova 4 ne valja i ukazuje ili na hardverski problem (smaknut hladnjak), bagoviti drajver ili na los sistem (laptopovi su obicno krivci) gde je OEM raspisao neki sampionski SMM kod (mislim da je ovo danas sve redja i redja pojava kako je UEFI standardizovao gomilu stvari koje su nekada resavane proprietary kodom).
Mislim da se vecina problema nalazi u ovih 4 stavki.
Kad smo kod RTOS-eva, secam se vrlo komicne situacije gde su performanse softvera na jednom od poznatijih RTOS-eva bile katastrofalno lose (isti CPU, ali razlika izmedju Linuxa i RTOS-a k'o nebo i zemlja) - analiza problema je ukazala na inverziju prioriteta niti. Ko god da je pisao kod i nitima dodelio neke prioritete je stvar testirao na Linuxu i Windows-u gde je sve bilo OK (tj. "OK" pukom srecom), ali na konkretnom RTOS-u je scheduler vrlo bukvalno shvatao to sto se trazi od njega i dosledno blokirao nit koja proizvodi podatke dok se druga nit koja ceka na iste podatke vrtela za dzabe dok joj ne istekne alocirano vreme i RTOS pusti nesrecnog producer-a da nesto stvori.
Zakljucak iz te price je bio da se ne za*bavas sa proizvoljnim setovanjem prioriteta nitima osim ako zaista ne znas tacno sta ce da se desi u svim rezimima rada, sto vrlo verovatno nije bio slucaj, nego je neko primenio cargo-cult programiranje i nasetovao nekakve prioritete nitima iz nekog samo njemu objasnjivog razloga.
Drugi zakljucak je bio da RTOS-evi vrlo dosledno izvrsavaju ono sto se trazi od njih, cak i kada je to katastrofalna greska, RTOS ne diskriminise, ako si trazio da ti urnise proces, to ce uraditi bez problema.
Razlog sto se problem nije vidjao na Linuxu ili Windowsu je ideja "fer" schedulinga ugradjena u standardne Windows i Linux scheduler-e (i nit niskog prioriteta ce dobiti duzi slajs ponekad zbog "fer" raspodele) - iliti, kernel dev-ovi znaju da je vecina userland koda sampionska i da moraju ponekad da ispeglaju tudje gluposti, cak i ako to nije posao OS schedulera.
U stvari tek tad vidis genijalnost ljudi koji su razvijali popularne scheduler-e u Linuxu/Windows-u/Mac OS-u - njihov problem nije bio razviti scheduling algoritam koji nitima alocira neki % procesorskog vremena po nekoj formuli, vec peglanje beskonacne kolicine idiotizama u userland kodu koji korisnici ocekuju da ce da radi bez problema, iako programeri bukvalno traze od procesa da se samoubije sto se performansi tice.
DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos:
http://www.digicortex.net/node/17 Gallery:
http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! -
https://github.com/psyq321/PowerMonkey