Java on Linux - leveraging MP?

[Frank D. Greco]

From what I understood, pre-Java 1.4.2 threading couldn't take advantage
of multi-processors on pre-Linux 2.5. Since before 2.5, Java on Linux
used green threads, ie, user-land threads, because Linux kernel threading
was sub-optimal (to put it mildly).

[With NPTL on Linux 2.6 (e.g., EL 3 kernel), this supposedly is fixed]

But in my tests with 1.4.2_05 on RH Linux 2.4.9-e38 (ie, similar to
regular Linux 2.5/2.6), I see all 4 processors being used when I run
a test pgm that just threads off a small runnable. I'm not using NPTL
and the new EL 3 kernel with the new kernel thread implementation.

I was expecting one processor to take the hit and the other processors
being idle.

Does anyone know if perhaps Red Hat perhaps cleaned up the Linux kernel threads
a bit in their 2.4.9-e38 (love the Linux numbering schemes...) to make them
work a little better?

Frank G.
+==========================================+
| Crossroads Technologies Inc. |
| www.CrossroadsTech dot com |
| fgreco at REMOVE!cross!roads!tech!dot!com|
+=========================================+

 

[Michael Borgwardt]

From what I understood, pre-Java 1.4.2 threading couldn't take advantage
of multi-processors on pre-Linux 2.5. Since before 2.5, Java on Linux
used green threads, ie, user-land threads, because Linux kernel threading
was sub-optimal (to put it mildly).

Java on linux stopped being based on green threads *way* before both Java 1.4
and Linux 2.5; the last time I heard about green threads being used was when
there wasn't yet an official Sun JRE for Linux.

This article from Sun confirms it:
http://java.sun.com/developer/technicalArticles/Programming/linux/

 

[Steve Horsley]

From what I understood, pre-Java 1.4.2 threading couldn't take advantage
of multi-processors on pre-Linux 2.5. Since before 2.5, Java on Linux
used green threads, ie, user-land threads, because Linux kernel threading
was sub-optimal (to put it mildly).

[With NPTL on Linux 2.6 (e.g., EL 3 kernel), this supposedly is fixed]

But in my tests with 1.4.2_05 on RH Linux 2.4.9-e38 (ie, similar to
regular Linux 2.5/2.6), I see all 4 processors being used when I run
a test pgm that just threads off a small runnable. I'm not using NPTL
and the new EL 3 kernel with the new kernel thread implementation.

I was expecting one processor to take the hit and the other processors
being idle.

Does anyone know if perhaps Red Hat perhaps cleaned up the Linux kernel threads
a bit in their 2.4.9-e38 (love the Linux numbering schemes...) to make them
work a little better?

Try writing a tight loop and see if all 4 processors hit 100%. I don't know about
Linux, but I know I ran a tight loop (single-threaded) on Windows NT once, and it
pushed both processors on a 2-CPU machine to 50%. I took this to be because
the thread was being scheduled on one of the two CPUs more-or-less at random
whenever there was a task switch - the task wasn't confined to one CPU even
though there was only one thread. So what I am trying to say is, that the work
may be being spread around the processors without being parallel. You can only
assume they are running fully parallel if all the processors go to 100%. If four
CPUs all jump to 25% then it is not properly multi-processor.

Steve

 

[JQ]

From what I understood, pre-Java 1.4.2 threading couldn't take advantage
of multi-processors on pre-Linux 2.5.

Absolutely it could. Java for many years has used a 1:1 threadrocess
model and each Linux process is scheduled in SMP fashion. The
green-thread model was to implement a scheduler within a single process
and timeslice it's own Thread implementations.

I think blackdown's distro moved off of that pre-1.2.

The new threading libraries scale better than the process-level
threading, but you should see quite good SMP performance on any
moderately-recent Linux/JVM combo.

 

[JQ]

because the thread was being scheduled on one of the two CPUs
more-or-less at random whenever there was a task switch

NT's and Linux's schedulers practice inherent process affinity where the
OS will attempt to reschedule a single process/thread on the CPU it had
executed before it's last context switch. This is to increase cache
hits ratios for speed.