Another voice heard from on the Linux threads issue:
> Anyone out there know the answer to this one?
And the answer is: tasking!
Here is an article from comp.os.linux.development dealing with the issue:
----
I was reading about IBM's 1.1.8 JDK, and the press release claims Linux has a problim with its thread implementation. Is this correct, and if it is, what exactly is the problem?
The press release also claims each thread have a separate process, is this true?
And of course are there any obvious improvements one could use to solve this "alleged" problem?
Here's an excerpt from the article:
*********
IBM's Java group will continue to focus on enhancing Java performance on Linux, in particular with an eye to solving its limitations in scaling. IBM's 1.1.8 port has performed well on the VolanoMark benchmark when the number of simultaneous chat sessions is limited, but the port has had difficulty scaling to a large number of simultaneous sessions.
This is due, in part, says Rajiv Arora, a senior performance engineer at IBM Austin, to the manner in which Linux handles threading. By using native threading, IBM's JVM can exploit symmetric multiprocessor (SMP) systems, something none of the other Linux JVMs can. However, the current implementation of Linux threading, where each thread is mapped to a separate process, is just too heavyweight to scale to thousands of threads. A number of options are being considered by IBM to enhance the connection scaling of future Java releases, despite the limitations of Linux threads.
**********
The entire article is available at:
ibm.com
The crux of the matter is that Linux threads are very crude and are implemented as secondary entry points into an existing process. Thus a thread appears to the operating system as just another process entry which needs to be scheduled just like any other process. Since the schedule evaluation is already expensive and runs in linear time, adding more process entries does not result in fast thread switching times. In other words, the implementation is cute but inefficient.
The biggest problem I see with the approach is that Linux has no idea that tasks cluster together. If a process has two tasks A and B, if A yields and B is ready to run, Linux is just as likely to run another process as it is to run B. Most other systems, particularly real time systems, will attempt to run B first as long as the process has not exhausted its time slice or no other process/task of higher priority is ready to run. Java tends to create lots of small tasks and it wants to switch rapidly between them, something Solaris threads is optimized towards (I also imagine AIX makes the same optimizations). The Linux scheduling strategy is very poor for making rapid tasks switches, hence the problem.
Many Unix developers do not understand tasking as used in real time systems. I have seen lots of outrageous claims in the Linux news groups usually along the lines that no one should ever write more than a handful of threads. Too bad most of these people never worked with early Unix and its very light wieght processes (and fast context swaps) or with other systems that had good tasking (Data General AOS or MP/AOS from the late 1970's had great tasking facilities -- that is where I learned software engineering). Many industrial control systems use one or more tasks for each piece of equipment or sensor in the system. No task runs for more than a few milliseconds and many tasks do not
run with any great frequency. Modularizing at the task level makes it easy to modify the system and leads to a rather simple design. Dropping everything into a single loop as most modern Unix hackers propose leads to a very complex and troublesome design. In effect, you end up writing a custom task dispatcher which is a lot more complex than using the operating system facilities. Alas, too many people do not understand the complexities of the real world or the alternative techniques of the past.
David |
