as requested by pusakat :) > > How does M:Ncpus differ exactly from M:N ? >
in M:N N is a dynamic number of kernel contexts in M:Ncpus N is the number of cpus. Any number of threads is managed by these fixed number of kernel contexts > > Besides thread/process creation time, there is the issue of context > switching. Now, process context switching will admittedly introduce > more overhead than thread context switching, but we are also led to > believe that under Linux, the penalty is much smaller(?) than on > traditional Unix. > Yes the context switching is the main tradeoff with 1:1 but is simplier because you only have a single scheduler to deal with. And kernel level threads are more expensive than user level threads ie PMPthreads vs Linuxthreads. > > So I've been wondering from way back: if NPTL threads are > so efficiently spawned and scheduled, can't the same apply > to 2.6 fork()ed processes? > > > If you use clone(), you are not portable, but why can't fork() > be nearly as efficient as NPTL threads (or at least exhibit > similar dramatic improvement compared to the old fork() ) > since they are both based on the same underlying clone() > call?? > Isn't that like asking why cant be processes be made efficient as threads > > What special feature of 2.6 does NPTL take advantage of? futexes? > Anything else besides that? And can't we apply something similar > to fork()ed processes? > afaik, the NPTL project actually added changes to 2.6 for it to have a good thread implementation 1. extended clone() 2. changes to retain the 1:1 model M:N would have been necessary necessary to go beyond the threads per process limit. 3. changes to various system calls 4. /proc was modified to handle more processes and not to include all threads, in a 1:1 model this would be chaotic if all threads was in /proc. 5. etc > > fork(), in many ways, offers a far cleaner API than pthreads, > so if we can get an efficient fork() on top of 2.6's clone(), > we can shun the overengineered pthreads API (and threads in > general) and get greatly improved performance for both new and old > fork()-based unix code (the latter, probably without even needing > to recompile). > Maybe they can't change its behavior and purpose(for processes) so they came up with clone() and several ?fork() system calls which has support for threads > > Such code would not be very efficient on other unixes, but would > still compile properly... and assuming the above scenario holds, > would fly on Linux without all the nastiness of thread programming. > I think if that was possible in the first place threads would have not been employed further. Lengthy discussions of problems with threads would have produced the consensus of avoiding it altogether. Thanks -- Eduardo Tongson http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6033AC66 -- Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Official Website: http://plug.linux.org.ph Searchable Archives: http://marc.free.net.ph . To leave, go to http://lists.q-linux.com/mailman/listinfo/plug . Are you a Linux newbie? To join the newbie list, go to http://lists.q-linux.com/mailman/listinfo/ph-linux-newbie
