2.6.16 kernel officially out
Posted by Fraser Campbell Thu, 23 Mar 2006 01:00:00 GMT
Several days ago Linux kernel 2.6.16 was announced on the kernel list. Archive posting here.
Since this is very likely to be the kernel in SLES 10 and it is very close to the kernel in Fedora Core 5 it certainly warrants a close look. RHEL 5 is more likely to get a newer kernel since it will not be out until the end of the year.
Interesting additions (in my opinion) are:
- page migration
- oracle cluster filesystem 2
- preliminary patches to support Niagara T1 processor (8 core sparc)
- preliminary patches to support IBM’s Cell processor (9 cores)
- numerous security patches as a result of recent coverity code analysis
Page migration allows the physical location of memory pages to be moved between nodes (generally CPUs) in a numa system while the process is running. To quoting the kernel documentation:
Page migration allows the moving of the physical location of pages between nodes in a numa system while the process is running. This means that the virtual addresses that the process sees do not change. However, the system rearranges the physical location of those pages. The main intent of page migration is to reduce the latency of memory access by moving pages near to the processor where the process accessing that memory is running.
The page relocation code will (in some cases) be executed automatically when a process is moved from one node to another, in other cases the migration of pages is triggered manually from userspace.
Now that the basis for page migration is in the kernel some future uses are sure to be found – memory hotplug and memory defragementation (to make room for large pages) come to mind immediately.
Oracle Cluster Filesystem 2 finally being in the kernel is a big win on many fronts. I see immediate uses in my work on virtualization as a shared storage filesystem for multiple Xen virtual machines. Clustered filesystems could also be used as the basis for psuedo live migration down the road … dump memory to disk, shutdown domain, reload mem on other node, start domain (this would only be necessary on nodes where networking has failed or for some other reason live migration is not an option).
