On Wednesday 26 June 2002 16:21, Petru Paler wrote: > > *Trebuie* reincarcate. Gandeste-te la starea registrilor, prioritatile > de scheduling, stack frame, etc. Daca nu ar fi reincarcate atunci nu ar > mai fi "schimbare" a firului de executie.
Apropos de prioritate de scheduling. Sa zicem ca un proces are prioritate f. mica si se executa cam 10ms/1sec. Are doua threaduri. Daca threadurile sunt tratate ca proces atunci acesta nu se va executa 20ms/1sec ? Stiu ca exemplul e deplorabil dar intelegi ideea. > > Fiindca tot vorbeam de schimbat fire: switchurile intre taskuri care > sunt clonate cu CLONE_VM nu fac TLB flush. Te referi cumva la asta cand > zici "nu ar trebui reincarcate toate datele"? :) Nu vad vreun motiv sa faci TLB flush cand faci switching intre taskuri. Poate gresesc dar chiar nu vad de ce ai face TLB flush daca nu swapezi. > > Uh-huh. Mai rapid decat ce? Stii desigur ca Linux are printre cei mai > rapizi timpi de task switching, nu? Asta cand vorbim de procese normale > -- daca ajungem la procese clonate deja treaba e _extrem_ de rapida. Si > stii de ce e asa? Din cauza simplitatii pe care ti-o confera conceptul > de "nu exista decat procese" (sau "nu exista decat threaduri", depinde > de terminologia pe care vrei sa o folosesti). > Eu unul nu vad nimic simplu pe aici. Deja am mai multe intrebari decat la inceput. Stii e ca atunci cand crezi ca stii ceva si te bagi mai adanc in problema si iti dai seama ca e cam nasol. :) > > > Nu trebuie sa se faca mapare pe infrastructura de procese. E mai lent > > context switch-ul (intre fire ale aceluiashi proces). Scheduler-ul ar > > trebui sa planifice fire, nu procese. > > Mi-e teama ca nu inteleg ce vrei sa spui. Nu ar trebui sa se faca mapare > pe infrastructura de procese? Atunci unde? Ajungi la ceva gen Pth care > nu poate beneficia de masini SMP. E mai lent context switchul intre fire > ale aceluiasi proces? Nu, e mai rapid (vezi discutia de mai sus despre > TLB). Nope. Cred ca ar trebui sa existe doua schedulere. Unul pt. taskuri altul pt. threaduri. > > Exact, QED, dar la concluzia diametral opusa :) Imbunatatirea > substantiala pe NT (si banuiesc si pe Solaris, si pe alte OS-uri care au > un concept separat de LWP) se datoreaza faptului ca pe NT comutarea > proceselor e INGROZITOR de lenta. Practic, e o trecere de la "foarte > lent" la "rezonabil" fata de "foarte rapid" la "un pic mai rapid decat > foarte rapid". E foarte usor sa te pacalesti luandu-te dupa "de 3 ori > mai rapid" -- uita-te la cifrele absolute ca sa-ti faci imaginea exacta > despre ce inseamna de fapt un task switch. LMbench is your friend :) Cum > reuseste Linux sa fie atat de rapid? Cum am spus si mai sus: simplitate, > simplitate, simplitate. > > Threadul despre kernel threads (pun intended :) pe Linux pare sa apara > cu o periodicitate destul de precisa, dar concluziile sunt tot timpul > aceleasi: Linux ARE suport pentru kernel threads, si merge BINE. NU zice > nimeni ca e perfect (a se vedea problemele cu semnalele si threadul de > management din librariile linuxthreads) dar NU sunt probleme grave si se > lucreaza la ele (ma astept ca NGPT sa inlocuiasca total linuxthreads > dupa ce va apare urmatoarea serie de kernele stabile). > E prima discutie despre asta la mine :) M --- Pentru dezabonare, trimiteti mail la [EMAIL PROTECTED] cu subiectul 'unsubscribe rlug'. REGULI, arhive si alte informatii: http://www.lug.ro/mlist/
