Slashdot Mirror
IBM's JFS & PTh-NG Reaches 1.0
jd writes "IBM's Journaled Filing System becomes the second commercial filing system for Linux to reach the exalted 1.0 status! It also follows close on the heels of another of IBM offering, the PThreads Next Generation project, which also hit 1.0 today." Check out this LWN story on it as well. It's worth noting that this is a free as in open source version - GPLed. There will be another commericial version as well.
The way I see it, this IBM project is just reinventing LinuxThreads with a few differences, the biggest being M:N threading. If you look at their list of known issues listed in the release notes, it's about the same as for LinuxThreads: no process shared mutexes, no process identity for threads (except when only one underlying system task is used). These two are the biggest sources of complaints from some LinuxThreads users.
The rest of my comments have to do with M:N, specifically the false claim that M:N provides a performance enhancement for all multithreaded applications.
I don't believe that M:N threading is a good idea It creates issues and complications in the library implementation. The responsibility of scheduling and dispatching is divided between user space and the kernel instead of being done in one place. What M:N threading does is speed up voluntary context switches---context switches that take place within a threading function that is directly or indirectly invoked by the application, such as a synchronization function (pthread_cond_wait, pthread_mutex_lock, etc). Such a function can just call the user space scheduler, which can dispatch a thread without cooperation from the kernel. This is how M:N reduces overhead.
M:N does nothing for involuntary context switches, which have to somehow go through the kernel (for example, a signal is delivered to the process, which swaps context so that returning from the handler will cause a new thread to run). Actually, this kind of context switch can be worse than the ordinary Linux kernel context switch, depending on how it is done. The current task is interrupted to run kernel code (transition 1). Then a handler in user space is dispatched (transition 2). Then the handler returns to the kernel (transition 3) then the kernel passes control back to user space with a new context (transition 4). On the other hand, a native context switch is just two transitions: interrupt the current task, and dispatch the new one. In any case, the kernel is involved in the involuntary context switches of the so-called ``user space'' scheduler, which puts their expense in about the same ballpark as a kernel task switch (within the same address space).
So what about the faster voluntary context switches that M:N provides? Unfortunately, most of the *useful* voluntary context switch points are in the kernel: such as blocking calls that wait for I/O or real-time events. So M:N does nothing for I/O or response to real-time inputs. Dispatching a response to the completion of I/O or a real time input always requires a switch from the kernel to the user process.
M:N also does nothing for compute-intensive multithreading that is done *sanely*. Sure, M:N may speed up a program that performs, say, some operation on a large matrix using 50 threads on two processors, because when these threads synchronize, it can be done using those fast voluntary context switches. But M:N will do nothing for a program that uses two threads over two processors to do the same thing, which is the more sane design.
As a rule, the number of threads in an application should be not much more than the minimum that is required to utilize the various functional units of the hardware (processors and peripherals). Using too many threads just causes wasteful context switches that accomplish nothing, increases the memory access footprint of the application (since each thread has its own private data areas, such as the stack), and causes the scheduler to have to choose from among more threads.
It's not worth trying to speed up brain-damaged applications that make poor use of threads, yet this is exactly what M:N is for.
[punch /tmp]$ diff -u xfs_announce jfs_announce
... It is a
--- xfs_announce Tue May 01 08:19:51 2001
+++ jfs_announce Thu Jun 28 14:30:02 2001
@@ -1,10 +1,12 @@
-SGI is pleased to announce the 1.0 release of XFS, high-performance
-journaled file system for Linux.
+IBM is pleased to announce the v 1.0.0 release of the open source
+Journaled File System (JFS), a high-performance, and scalable file
+system for Linux.
-http://oss.sgi.com/projects/xfs/
+http://oss.software.ibm.com/jfs
-XFS, widely recognized as the industry-leading high-performance
-filesystem, provides rapid recovery from system crashes and the
-ability to support extremely large disk farms.
-mature technology that has been proven on thousands of IRIX
-systems as the default filesystem for all SGI customers.
+JFS is widely recognized as an industry-leading high-performance
+file system, providing rapid recovery from a system power outage or crash and the
+ability to support extremely large disk configurations. The
+open source JFS is based on proven journaled file system technology
+that is available in a variety of operating systems such as AIX and
+OS/2.
;-)
What about ReiserFS and XFS? Or is there some weird meaning to "commercial filing system" that I don't get?
A post with Score: 6 has appeared on slashdot before (anyone remember it?). This suggests that there was a race in slashcode; and since slashdot still uses a non-transactional data store, I bet the it's still there. I think everyone gets where I'm going with this.
So, here's the plan: First, someone moderates this back down to 4. Second, everyone with mod points synchronizes their clocks to UTC (apt-get install ntp). Third, everyone picks an appropriate (positive, smartass) moderation for this article and moves their pointer over the "Moderate" button. Fourth, at exactly midnight (00:00:00 UTC, June 29), everyone clicks "Moderate".
Everyone without mod points places bets on how high we can get this sucker.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
GPLGP
LGPLGPL
GPLGPLGPL
GPLGPLG
PLGPLIBM
GPLGPLG
PLGPLGPLG
PLGPLGP
LGPLG