Linux Multithreading Advances
Pages: 1, 2
New Generation POSIX Threads
A group at IBM and Intel, led by Bill Abt at IBM, released the first version of the New Generation POSIX Threads (NGPT) library in May 2001. This consisted of a drop-in replacement for LinuxThreads, together with patches for kernels beginning with 2.4.0.
To ease acceptance, the group made a conscious effort to keep the impact on the kernel small. They worked to get the kernel modifications they needed through patient, piece-by-piece promotion and expected to have NGPT eventually replace LinuxThreads in the glibc system.
NGPT is a derivative of the GNU Pth (GNU Portable Threads) package, which up to now is based on an M:1 model. A user space priority and event-based, non-preemptive scheduler manages the M user threads. This was seen as an improvement over the 1:1 pure kernel thread model used by LinuxThreads where the kernel has to do a lot of scheduling work.
NGPT adopted the M:N hybrid model. Many developers saw this as the best path to good performance: keep all CPU's humming, minimize context switching between kernel threads, and switch mostly between user space threads. However, the M:N model is complex. It requires two cooperating schedulers, one each in user and kernel space. Signal handling is difficult and much work has to be done in user space. It takes fancy footwork to prevent one blocked thread from blocking other threads running in the same process.
Nonetheless, the NGPT team succeeded in implementing the full pthreads standard, and the kernel changes they needed were accepted in the mainline kernel early in the 2.5 development process (at kernel 2.5.4). They were also back-ported into the 2.4.19 kernel. Depending on the metric used, performance gains were claimed of up to 100 percent, and work continues on improvements.
On March 26-27, 2002, Compaq hosted a meeting to discuss the future replacement for the LinuxThreads library. In attendance were members of the NGPT team, some employees of (then distinct) Compaq and Hewlett-Packard, and representatives of the glibc team, including the head maintainer, Ulrich Drepper (a Red Hat employee), who wrote a summary of the meeting.
Pursuing the M:N approach, the report said:
"This is one of the reasons why it is absolutely necessary to think about two-level scheduling for the threads. I.e., the actual user threads are different from the kernel threads (or light-weighted process, or what ever one wants to call them) and scheduled separately. This is generally called the M-on-N model for a thread implementation. The 1-on-1 model dedicates a unique kernel thread for each user-level thread; this is the model used by the current, inadequate thread library implementation."
The report contains detailed analysis of how to get kernel and user-space schedulers to cooperate using the scheduler activations method.
It seemed the replacement for LinuxThreads would be based on NGPT.
Native POSIX Thread Library
On September 19, 2002, Ulrich Drepper and Ingo Molnar (also of Red Hat) released an alternative to NGPT called the Native POSIX Thread Library (NPTL). The project included a new user space library, changes to glibc, and kernel modifications. The initial announcement said in part:
"Unless major flaws in the design are found this code is intended to become the standard POSIX thread library on Linux system, and it will be included in the GNU C library distribution."
NPTL is based squarely on the 1:1 pure kernel thread model. A white paper explains why in detail.
Recent changes to kernel thread handling (mostly due to Ingo Molnar) had vastly improved thread performance. With these changes in place, the relative simplicity of the 1:1 model became very attractive.
There is only one scheduler. Signal handling remains in the kernel's hands. Blocking problems are handled naturally because each kernel thread schedules independently. In addition, the user space implementation becomes fundamentally simpler.
In some sense, one has come full circle; developers who wanted to ensure full Posix compliance were frustrated by the kernel maintainers' unwillingness to adapt the Linux kernel to fit their needs, and thus NGPT was developed in part as a polite end run requiring minimal kernel changes. Then a programming tour de force, mostly by one key kernel programmer, is now claimed to enable reversion to a much simpler approach.
Linux Kernel Improvements
What changes have been made in the Linux kernel to make threads perform and scale better?
Consider the previous example of obtaining a new
potentially quadratic search is gone. Instead, the kernel sets aside a small
but dynamic number of memory pages as bitmaps for process identifiers.
Obtaining a new
pid means finding a page with free entries and
then finding and clearing the first set bit. No locking is required, and the
search time is very short and almost independent of the number of running
Another key improvement is the
O(1) scheduler, which no longer
has to cycle through all processes to find the most deserving one. Each CPU has
its own queue, a simple priority-sorted bitmask. Once again finding a new
process is very fast and scales fantastically.
Where Do We Go From Here?
The NPTL team posted some benchmarks, such as this display of the minimum time needed to create a number of top-level threads.
In general, while NGPT beat the old methods by a factor of two, NPTL could do better by another factor of two.
It remains to be seen exactly how the two implementations will rank against each other. NGPT may not yet be tuned to take advantage of recent kernel improvements the way NPTL has. Furthermore, benchmarks are often used to misrepresent. It will take further development by both teams, independent benchmarks, and real life comparisons to see who really beats whom.
You can test drive NGPT by simply downloading the library and installing it, as long as you have kernel 2.4.19 or later. For NPTL,
you can download the library, but you will need a very recent development
kernel as well as bleeding edge
gcc. The announcement contains
While there may be some hard feelings on the socio-political side about how NPTL seemed to come out of the blue, the maintainers of NGTP have not griped in public. It seems that any battle between the two implementations will now be played out in public, in good open source fashion. Either one library will win out over the other, or each will become the preferred tool in some universe for some load. At any rate it will be fun to see what happens. Linux will benefit by having a standards-compliant, and well-performing threads implementation(s).
Return to the Linux DevCenter.
- Trackback from http://www.punknix.com/archives/2003_03.html#000015
NPTL wins over NGPT
2004-09-02 20:22:12 [View]
- Trackback from http://birdhouse.org/blog/archives/001215.php
2004-02-07 23:48:55 [View]
2003-05-27 07:43:59 coop [View]
NGPT versus NPTL
2003-05-25 10:00:36 anonymous2 [View]
Multiple schedulers for the same game?
2002-11-13 16:28:01 anonymous2 [View]
2002-11-11 11:51:31 coop [View]
NGPT and NPTL use the same API?
2002-11-10 20:50:56 anonymous2 [View]
See this similar comparison
2002-11-09 10:48:53 anonymous2 [View]
2002-11-09 10:36:23 anonymous2 [View]
Scalability should be the main focus
2002-11-09 05:49:22 anonymous2 [View]
Lazy IPC (as seen in L4)
2002-11-09 03:13:50 anonymous2 [View]
Cooperative Threads 0wn3r!!!
2002-11-09 01:03:32 anonymous2 [View]