If commercial Unix vendors weren’t already worried about Linux, they should be now. Linux has seen wide deployment in datacenters,
generally as a Web server or a file server, or to handle network tasks such as DNS and DHCP, but not as a platform for running
mission-critical enterprise applications. Solaris, AIX, or HP/UX typically get the nod when an application demands the highest
levels of performance and scalability. The recent release of a new Linux kernel, v2.6, promises to change that.
The v2.6 kernel ushers in a new era of support for big iron with big workloads, opening the door for Linux to handle the most
demanding tasks that are currently handled by Solaris, AIX, or HP/UX. The new kernel not only supports greater amounts of
RAM and a higher processor count, but the core of device management has changed. Previous to this kernel there were limits
within the kernel that could constrain large systems, such as a 65,536 process limit before rollover, and 256 devices per
chain. The v2.6 kernel moves well beyond these limitations, and it includes support for some of the largest server architectures
around.
Will the new Linux really perform in the same league as the big boys? To find out, I put the v2.6.0 kernel through several
real-world performance tests, comparing its file server, database server, and Web server performance with a recent v2.4 series
kernel, v2.4.23.
Linux Meets Big Iron
A primary focus of the v2.6 kernel is large server architectures. Support for up to 64GB RAM in paged mode, the ability to
address file systems larger than 2TB, and support for 64 CPUs in x86-based SMP systems brings this kernel and Linux into the
more rarified air of truly mission-critical systems. The included support for NUMA (Non-Uniform Memory Access) systems; a
next-generation SMP architecture; and PAE (Physical Address Extensions), providing support for up to 64GB of RAM on 32-bit
systems, is also new.
There is much more to v2.6 than just bigger numbers in processor and RAM counts, however. This kernel breaks apart some of
the artificial limitations that have been present in Linux from the beginning, such as the number of addressable devices and
total available PIDs (Processor Identifiers). The v2.4 kernel supported 255 major devices with 255 minor numbers. (For example,
a volume on a SCSI disk located at /dev/sda3 has a major number of 8, since it’s a SCSI device, and a minor number of 3.)
On servers with a large number of real or virtual devices, device allocation can become problematic. The v2.6 kernel addresses
these issues in a big way, moving to 4,096 major devices with more than one million subdevices per major device. For most
users, these numbers are well beyond practical limits, but for enterprise systems with a need to address many devices, it’s
a major step.
Also new in v2.6 is NPTL (Native POSIX Threading Library) in lieu of v2.4’s LinuxThreads. NPTL brings enterprise-class threading
support to Linux, far surpassing the performance offered by LinuxThreads. As of October 2003, NPTL support was merged into
the GNU C library, glibc, and Red Hat first implemented NPTL within Red Hat Linux 9 using a customized v2.4 kernel.
Other goodies in the v2.6 kernel include integrated IPSec support, with the inclusion of the Kame Project; enhanced support
for network file systems, including support for mounting Novell NetWare shares; initial NFSv4 (Network File System Version
4) support; and performance and compatibility enhancements with SMB (Server Message Block) shares, including support for CIFS
(Common Internet File System). The v2.6 kernel also sports a brand new security architecture that departs somewhat from the
standard Unix root user concept; its modular security mechanism provides a greater level of granularity to privileged user
management.
Also introduced in the v2.6 kernel is a new approach to devices. The v2.4 kernel’s devfs-based device handler has a companion
in the v2.6 kernel. The newcomer is udev and is an implementation of devfs, but in userspace. Using udev, the system is able
to follow devices as they move around on connected busses, with the device identifier remaining static. For instance, the
first-seen SCSI device will remain as device sda, using the serial number of the device as an identifier regardless of the
order in which it’s found during a later boot. The use of udev is a significant change at the core of the kernel and the cause
of some consternation among Linux kernel developers, with solid arguments provided by both sides. It looks like udev/sysfs
will be the standard in the future, deprecating devfs, but both are present in the v2.6 kernel and are likely to remain for
some time.
And yet another significant change to the v2.6 kernel is the merging of the uClinux project into the core kernel. The uClinux
project has been focused on Linux kernel development for embedded devices. The main drive for this functionality is support
of processors lacking MMUs (Memory Management Units), commonly found in microcontrollers for embedded systems such as fire
alarm controllers or PDAs. The list of embedded controllers that v2.6 supports is quite long, including common processors
manufactured by Hitachi, NEC, and Motorola. This definitely shows a separation from the roots of the Linux kernel, as all
prior kernels were more or less subject to the limitations of the Intel x86 architecture.
Built for Speed
Prior to the release of the v2.6 kernel, Linux performed tasks on a first-come, first-served basis; interrupting the kernel
midtask to handle another process or function was not in the cards. The v2.6 kernel, however, can be pre-empted when needed,
and can allocate resources for a process that requires immediate attention, then resume processing on the interrupted task.
These interruptions are measured in fractions of a second, and are not generally noticeable, but rather lend an overall feeling
of smoothness to system performance. The v2.6 kernel does not bring Linux to the point of being an real-time operating system,
but it goes a long way toward assuring that tasks are addressed and completed when required.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
