Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is 2.3.99-pre6. This kernel, which came out on April 26, is the first since April 11. The fact that Linus is changing houses may have something to do with the long interval between releases.
The (3.6 MB) 2.3.99-pre6 patch consists mostly of small tweaks to over 900 files; there is also more i386 interrupt handling work, a number of small Sparc tweaks, some large I2O updates, an ISDN update, a driver for LAN Media synchronous serial boards, many changes to the IA-64 support for 32-bit binaries, the removal of kernel debugger support for the IA-64, a large 3c59x ethernet driver update, numerous SCSI subsystem tweaks, some sound driver updates including the incorporation of the EMU10K (SB Live) driver, and some ATM networking updates.
The removal of debugger support for the IA-64 is not entirely surprising - Linus has long had a dislike for interactive kernel debuggers. His position is that they lead developers to fix symptoms; he would rather they stare at the source and come to an understanding of the real problem. Thus, the real surprise is that KDB got in for a while in the first place.
Here is Alan Cox's 2.4 jobs list as of April 25.
The current stable kernel release is still 2.2.14. Alan Cox has had 2.2.15 ready to go for a while, but Linus has not yet released it. The 2.2.15 prepatch has moved forward to 2.2.15pre20, without announcement. Both pre19 and pre20 contain new security fixes that, one would hope, will see a mainline kernel release soon.
Meanwhile Alan has released a first 2.2.16 prepatch with a few larger items that won't go into 2.2.15. It contains some driver fixes (especially sound drivers), some new NLS codepages, and a number of other small changes.
poll() and the big kernel lock. A problem faced by any operating system once it begins to support multiple processors is controlling access to data that may be accessed by more than one processor at once. If multiple processors simultaneously manipulate the same data structures, chaos soon results. Back in the 2.0 days, Linux handled this sort of "mutual exclusion" problem with the "big kernel lock." Essentially, any time a processor went into the kernel it had to take out this lock; as a result, only one processor could be executing in the kernel at any given time.
That approach works, but its performance leaves something to be desired. Even with just two processors, quite a bit of CPU time will be wasted waiting for the big kernel lock. With more then two processors, the cost becomes unbearable. Thus, much work in the 2.1 and 2.3 development series has been aimed at the elimination of the big kernel lock in favor of more fine-grained locking schemes.
Much of the kernel runs without this lock at this point. One notable exception has been the implementation of the poll() and select() system calls. poll() uses the big kernel lock not because of any inherent need, but because nobody has gone through and made sure that all of the device drivers (which have a method used to implement poll() on their devices) will work without it. There are a lot of drivers out there, and auditing them all can be a long and unpleasant task.
The topic came up this week after some results were posted showing that the use of the big kernel lock in poll was creating some real performance problems in certain situations - such as on a busy web server. People began to wonder if the big lock was still necessary with poll(); after some discussion, Manfred Spraul posted a patch which removes the lock_kernel() calls from poll().
Resistance to this patch came from Alan Cox, who is very much trying to work toward a stable, releasable 2.4 kernel and is not pleased by a patch that could affect many dozens of device drivers. Alan appears to have lost the debate, however: Linus has come out in favor of the patch. As a result, a few driver maintainers may have to do a bit of last-minute scrambling to be ready for 2.4, but, as has been pointed out, these drivers needed to make their own synchronization requirements anyway to be safe on multiprocessor systems.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
April 27, 2000