Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is 2.3.31. This kernel was released without announcement, as is usual these days. This patch (1.2 MB) includes a lot of joystick driver work, an AGPGART driver (experimental), 3dfx support in the direct rendering manager, an Aironet 4500 network adaptor driver, and a major thrashup of the USB SCSI driver.
The current stable kernel release remains 2.2.13. The series of 2.2.14 prepatches continues, with 2.2.14pre12being the current release candidate, if all goes well.
Initial support for NUMA systems was quietly slipped into 2.3.30. NUMA stands for "non-uniform memory access"; a NUMA system is a multiprocessor system where, for each processor, the speed of memory access varies depending on the "distance" between the memory and the processor. Using NUMA, the usual performance bottleneck between the memory and the processors can be eased somewhat by providing a special path for each processor to a portion of the installed memory. As a result, NUMA systems more easily scale to larger numbers of processors.
NUMA systems look much like regular SMP systems, in that all memory is accessible by all processors. However, a system which does not take the NUMA speed differential into account will perform poorly. A NUMA-aware operating system will seek to maximize the locality of its memory references, so that it is running out of the fastest memory as much of the time as possible.
Linux has had part of this problem solved for some time: it already tries to avoid moving processes between processors. Even on uniform memory systems, each processor has its own memory cache that gets wasted when a process moves somewhere else.
On NUMA systems, however, each processor really needs to make a point of using its fast memory. And that is what the new code in 2.3.30 does. This code was written by Kanoj Sarcar, who has been doing quite a bit of kernel hacking at SGI. Kanoj's new NUMA code splits memory into regions associated with each processor. When a processor allocates new memory, it tries to do so from its fast pool if possible; otherwise it has to look farther afield. Currently non-local memory is allocated from other processors in a round-robin fashion; eventually that will be changed to a distance-sensitive search.
Much more can be done to improve performance on NUMA systems. For example, kernel code (and shared libraries too) can be replicated across processors so that each runs out of its fast memory. Trying to keep related processes (i.e. those which are sharing memory regions) together on the same processor can also be helpful. But one has to start by getting the underlying system in order; Kanoj Sarcar's work is a good step in that direction.
Should the kernel provide transparent, portable support for binary modules? That was the topic of this week's big battle in linux-kernel. The battle, for all its ferocity, remained somewhat one-sided, however...
In one corner, there is Kendall Bennett of SciTech Software, who started things off with a posting entitled Linux headed for disaster?. Therein he claims that Linux should make it possible to build binary modules which can be loaded into any version of the kernel. His claim is that the variety of hardware supported by Linux would be much wider if binary modules were supported in this manner. Without the need to continually port drivers to new versions, hardware vendors would be much more likely to provide drivers for Linux.
It is true that the problems with driver compatibility can be somewhat annoying. Even for a given kernel release and underlying system architecture, there are a number of variable which affect module compatibility, including:
The battle is one-sided because there is very little sympathy among kernel developers for those who wish to distribute binary-only modules. Indeed, they seem to relish the idea of making that task harder. And there are, in fact, good reasons for not trying to support binary modules across versions and configuration options:
Thus, people may complain - especially those who would like to make a living off distributing proprietary modules. But the situation is highly unlikely to change.
As an example of the sorts of problems that can arise with binary modules, look no farther than Lucent's release of a PCI modem driver, which was covered last week. This driver was built for Red Hat 6.1 systems, but even Red Hat users have been complaining about troubles making it work. Since no source is available, the problems can not be fixed, and the driver can not be built for any other distribution. According to this note, this situation is unlikely to change anytime soon. Those wanting to give this driver a try may want to grab the RPM versionput up by Definite Software.
Meanwhile, for those looking for a free Lucent PCI modem driver, LTModem 0.9.3 has been announced.
The ALSA Professional Team has announced its existence. ALSA, of course, is the "Advanced Linux Sound Architecture," the next generation of sound drivers for Linux. This new team consists of two developers (Jaroslav Kysela and Abramo Bagnara) who are being funded by SuSE to work full time on ALSA and bring it to some sort of initial completion within a couple of months.
The rumors of the QNX filesystem's death were premature. After having seen the discussion of the maintenance (or lack thereof) of the QNX filesystem last week, an eager kernel hacker (who wishes to remain unnamed for the moment) has stepped up and taken over the maintenance responsibility. QNX lives on...
Other patches and updates released this week include:
Section Editor: Jon Corbet
December 9, 1999