login
Search
Following last October's merge for SMP support [story], NetBSD has now merged support for native pthreads. The implementation by Nathan Williams and Jason Thorpe is a two-level thread system known as Scheduler Activations, as described in this very interesting and informative usenix paper by Nathan Williams. In a recent posting to the NetBSD-announce mailing list, Jan Schaumann explained:
"With the Scheduler Activations based work that Jason and Nathan made, this is a very efficient implementation that can map N userland threads to M kernel threads, and there is no need to have one kernel thread for each userland thread, like some other systems (used to?) have, and which kills performance for many threads."
For a complete explanation of the recent merge, read on for Jan's full email.
From: Jan Schaumann To: netbsd-announce Subject: NetBSD now has native pthreads! Date: Sun, 19 Jan 2003 17:14:49 -0500 http://www.netbsd.org/Changes/#merge-nathanw_sa After NetBSD supports symmetric multiprocessing (SMP) on a number of systems for some time now, support for native threads was added by merging the nathan_sw branch that contains a Scheduler Activations based threads implementation by Nathan Williams and Jason Thorpe. SMP means running processes on more than one CPU in parallel. (With some care-taking from the kernel that both CPUs don't step on each other with respect to writing to kernel data structures etc.). Threading means splitting up a process into several (well :) threads, and let them run on either one or more than one CPU. This is basically an application-layer issue, in contrast to SMP which happens inside the kernel. Having SMP available helps for performance in threads systems as threads can be ran in parallel on several CPUs, but SMP is not strictly necessary for a threaded system. Many applications today use a threaded software architecture (over the classical Unix "fork"ed processes), and so having some efficient threads implementation is an important goal of the NetBSD project. With the Scheduler Activations based work that Jason and Nathan made, this is a very efficient implementation that can map N userland threads to M kernel threads, and there is no need to have one kernel thread for each userland thread, like some other systems (used to?) have, and which kills performance for many threads. With native threads now available in NetBSD-current, applications from pkgsrc will readily pick it up upon rebuild, and things will be fixed over the coming time. For instructions on how to port existing applications and to use threads in your own programs using the new libpthreads that come with NetBSD now, see http://www.humanfactor.com/pthreads/. (Thanks to Hubert Feyrer for the detailed press release.) -- http://www.netbsd.org - Multiarchitecture OS, no hype required.
1:1 vs. M:N
Given the performance achieved by (Linux') NPTL threading library [story], it's hard for me to see why a 1:1 thread model "kills performance for many threads".
As Ingo Molnar [interview] said,
and
Finally, in this email, Ingo notes:
I personally think that the debate vs. M:N or 1:1 is superior is very similar to the debates about Linux vs. *BSD, monolithic vs. microkernels etc., but all in all, I also think it's not justified to claim that when you need "many" threads, 1:1 is inherently inferior to M:N.
--
schnee
Re: 1:1 vs. M:N
The difference over a "Linux vs. *BSD", "vi vs. emacs" is that you can easly measure which one is the better.
1:1 should be faster/better/more stable/... because:
- there is no extra scheduling overhead
- there is no extra data overhead
M:N should be f/b/s/... because:
- the kernel is not bloated w/ millions of threads
- the kernel is not bloated w/ millions of extra-data per thread
I believe that with the O(1) scheduler the 1:1 model will probably better, but so far (on stable OS release), the M:N model always outperformed the 1:1 model.
I guess in the linux side of the world we have the chance to have excellent developers trying out both model, and hopefully the best code/model will win!
Guillaume
Re: 1:1 vs. M:N
Although the rest of what you said is very valid, I don't think that this is true - the statement, after all, was not about a specific implementation for a specific OS or platform, but rather about the underlying thread model itself.
And of course, it all depends on the applications, too - depending on the application's own model, either thread model may be better than the other one.
Well - vive la diversité. :) I'm happy we're in a position where we actually can experiment with different threading models / implementations instead of just having to except whatever some vendor cares to throw at us. :)
--
schnee
P.S. Disclaimer: I don't know any french at all really, so what I said above may be horribly distorted... :)
Out of topic - your French
your French was correct indeed.
P.S. Disclaimer: I don't know any English at all really, so what I said above may be horribly distorted... ;)
Measures
I was not discussing about the OS or plateform but the model. You can measure which model is better in a rationnal way. The "linux vs. BSD" or the "vi vs. emacs" debate are not rational, because the measurement we are taking is our feelings or the way we are working.
I fully agree that the best model depends on your environment, applications, ... but you can still decide in non emotional ways. So as you said la diversité est une bonne chose
Guillaume
Re: 1:1 vs. M:N
IMHO there is a very good test for these models.
All you need to do - just run multithreaded Java application like J2EE PetStore under a considerable load.
Almost everyone knows that Java on Linux is SLOWER than Java on Solaris (M:N) and Windows (who knows, definitely WIN32 is NOT 1:1).
Somebody would like to say OK, it's due to different JVM implementation, memory management, locking management, filesystem, etc. But other types of the applications like Apache doesn't show this trend. Java is inherently multithreaded and therefore shows the difference in the most spectacular way.
Re: 1:1 vs. M:N
Almost everyone knows that Java on Linux is SLOWER than Java on Solaris (M:N) and Windows (who knows, definitely WIN32 is NOT 1:1).
FYI, with Solaris 9, Sun has switched from a MxN model to a 1:1 implementation. With very good results.
http://wwws.sun.com/software/whitepapers/solaris9/multithread.pdf
Re: 1:1 vs. M:N
> I personally think that the debate vs. M:N or 1:1 is superior is very
> similar to the debates about Linux vs. *BSD, monolithic vs.
> microkernels etc., but all in all, I also think it's not justified to claim
> that when you need "many" threads, 1:1 is inherently inferior to M:N.
Obviously you haven't read the Usenix paper, which is linked in the main story. Scheduler Activations have several advantages over 1:1 kernel threads. It's not about scheduler latency or how fast you can start&kill threads, but more like scheduling the right thread at the right time.
I really suggest that you read the paper, since it's a very interesting read and gives a better understanding of the problems involved with threads, why sometimes userlevel threads are faster, and why Scheduler Activations are a good compromise between the two.
It _is_ about latency, speed
I don't know what you thought it was about...? SA tries to get the intellegence of 1:1 with the speed of N:M. Having the kernel know about all threads blocking states (1:1) is fine for scheduling the right threads.
By the looks of the benchmarks, Linux 2.5 with NPTL (1:1) would fry SAs in threading operations, locking operations and context switching.
It might have some advantages I guess, though *BSDs often seem to have overengineered solutions... or perhaps it seems that way because they think of cool sounding names for things and describe them with a lot of big words! ;P
the term
Just to nit pick, NetBSD didn't invent the term "scheduler activations" -- it was introduced in the original paper on the subject (from 1992).
Credits
I'd just like to clarify the credits: I did not participate in the implementation, I merely posted the announcement to various sites. The overwhelming majority of the work performed on the nathanw_sa branch was done by Nathan Williams; while others helped out, he deserves most of the credit as Jason Thorpe, who actually merged the branch with HEAD, is happy to point out.