Linux's 2.6 kernel quickly won the PR battle with engineering redesigns that improved speed through better scheduling, memory use as well as better hardware support. But away from the PR battlefield, its differences from the widely installed 2.4 kernels could make its introduction a testing experience for enterprises.
If you have deployed an enterprise distribution that uses a modified kernel such as SuSE or Red Hat's Enterprise Linux series you may well see no net benefit from upgrading the kernel. That's because your 2.4.x kernel may already incorporate features that were back ported from the 2.6 kernel while the 2.6 kernel was still in its long beta.
More confusingly, "upgrading" to a 2.6 kernel may lose you features that the distribution vendor had coded into its 2.4.x kernel but which had not made it to the 2.6 kernel. Features that enterprises using RHEL 3 would lose through this include:
4GB-4GB memory splits that increase x86 memory
Scheduler support for symmetric multi-threaded CPUs (which includes most modern rack-mount SMP boxes, such as Dell's insanely popular PowerEdge series)
In reality, kernel 2.6 does have scheduler support for hyper-threading but Red Hat alleges its own code is more advanced.
And hyper-threading support is not the only reality that is much more challenging in the enterprise. Split memory and scheduler support are just two components in a much longer list of back-ported kernel 2.6 features that makes kernel comparison much harder.
Why? Because there's no low-cost way of assessing whether the improved kernel 2.6 feature is better than the vendor's back-ported feature. Unless, that is, you want to set up a full array of benchmarks and test against them or pay a properly equipped and staffed lab to do it for you. A more realistic solution is to depend on your vendor. SuSe, for example, expects to have a 2.6 version out this summer. Red Hat, is also testing its 2.6 kernel but doesn't expect to release a 2.6-based RHEL 4 until autumn.
Among the issues to test is real-world implementation of symmetric multi-threading, back-ported versions of which have been blamed for problems in some enterprise servers. For example, the 2.6 kernel still cannot tell the difference between real and virtual processors -- a disability for kernels working in high-load enterprise scenarios where load balancing should first balance loads across real processors before adding in virtual processors.
There are some kernel components for which low-cost comparison information will become available quite quickly. For enterprise database applications that rely on file input/output and memory, the 2.6 kernel improves maximum file size a key issue for the big binaries data structures that enterprise databases create. The potential revenue available from companies that care about this is so high that we can expect independent analysts to release test results as they promote their own consultancy services.
Other 2.6 database optimisation tricks will spread more slowly. Consider that much of the chatter about kernel 2.6 has focused on the schedulers, specifically the anticipatory scheduler (which pauses before switching from read to write operations in case more reads are required) and the process priority-controlling O scheduler.
But those studs of the IT world RDMBS administrators will love the less well-publicised deadline scheduler, which allows them to toggle off the anticipatory scheduler's read bias to favour database I/O needs. Do that by appending "elevator=deadline" to the kernel call in grub or lilo.
The raft of changes required to implement Non-Uniform Memory Access (NUMA) includes virtual memory improvements that will bring faster speeds on non-NUMA platforms too. But ask yourself how many times you have heard IT staff discussing NUMA and you'll quickly appreciate how unprepared most are to think about the details of NUMA optimisation.
Kernel 2.6's appeal to enterprises considering Linux on the desktop primarily revolve around speed improvements. Among a myriad of speed enhancements are process scheduler tweaks designed to benefit near-realtime embedded systems and which also improve desktop systems' responsiveness to external events such as mouse movements. That gain may not be visible unless distribution vendors also tweak XFree to override kernel 2.6's ability to prioritise display events over other events. This really is a problem: 2.6 beta mailing lists have been full of "jerky mouse" complaints and their associated "set XFree to 0" fix since soon after 2.6 betas were released.
Arguably though, kernel 2.6's most significant enhancements for enterprise systems could be the under-publicised improvement to its security model. To understand the importance of this, consider how you would apply an Access Control List (ACL) to a department in a company under Windows' security model. Now consider the hoops you would jump through to try to replicate Windows' level of granularity or its easy management of user rights on Linux. While kernel 2.6 doesn't make Linux access control quite as easy as it is under Windows, it is potentially much easier than it used to be.
Linux Security Modules (LSM) is a standardised framework that allows the kernel to check access calls against any developer-provided security mechanism. SELinux is the most well-known of those mechanisms and vendors, seeing the pain associated with Linux ACLs in the enterprise, have moved fast to write non-free tools around it: Red Hat and Immunix being two examples.
But LSM could be just one approach to more fine-grained Linux security: the LSM allows other security mechanisms for which third parties will probably write plug ins that offer Windows-style rights and permissions management.
Bless that day when it arrives!