Dorin Lazar wrote: > Pentru ca nu sunt decat contexte de executie. Cand se comunica nu se > comunica decat intre procese. Altfel e o brambureala totala (asha cum e acum > cu linuxthreads).
Unde anume e brambureala? Probabil ca te referi la problemele care apar cand amesteci threads si signals, dar alea sunt reparate de catre NGPT. > Vorbesc desigur din punct de vedere pur teoretic, desigur. > Practic, insa, in momentul in care se schimba firul de executzie nu ar trebui > reincarcate toate datele dintr-un task_struct (asha cum se intampla pe > linuxa). *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. 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"? :) > Thread switching should be a lot faster. 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). > CLONE_PID nu poti sa il foloseshti decat daca PID e 0. Adica daca PID-ul este > PID-ul procesului care porneste... Nu se mai foloseshte CLONE_PID doar in > momentul in care se da drumul la init. In sursa e un test de conditzie de > genul if (pid && CLONE_PID) return; De acord, incercam sa trolluiesc :) Oricum, daca PID-urile diferite sunt o problema atat de mare, nu cred ca ar fi mare dificultate sa fie implementate (probabil ca adaptarea ps/top/etc din userland ar fi mai multa munca decat ce trebuie facut in kernel). > 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). > Imi amintesc un benchmark pentru Apache 2 care arata o imbunatatire > substantiala pe NT dupa folosirea firelor de executzie, si o imbunatatire mai > putin evidenta pe Linux. QED. 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). Petru --- Pentru dezabonare, trimiteti mail la [EMAIL PROTECTED] cu subiectul 'unsubscribe rlug'. REGULI, arhive si alte informatii: http://www.lug.ro/mlist/
