Linux 2.6.37 Released 135
diegocg writes "Version 2.6.37 of the Linux kernel has been released. This version includes SMP scalability improvements for Ext4 and XFS, the removal of the Big Kernel Lock, support for per-cgroup IO throttling, a networking block device based on top of the Ceph clustered filesystem, several Btrfs improvements, more efficient static probes, perf support to probe modules, LZO compression in the hibernation image, PPP over IPv4 support, several networking microoptimizations and many other small changes, improvements and new drivers for devices like the Brocade BNA 10GB ethernet, Topcliff PCH gigabit, Atheros CARL9170, Atheros AR6003 and RealTek RTL8712U. The fanotify API has also been enabled. See the full changelog for more details."
Re:Kernel locking (Score:2, Informative)
Ubuntu will ship with this kernel in their next release Natty in April
Re:Kernel locking (Score:4, Informative)
"Well I'm glad they officially fixed the kernel lock. Out of curiosity, how long until Ubuntu or Debian sees this integrated into their line?"
Don't know about Ubuntu but since Debian is already "frozen" towards its next release (codename "squeeze") you can bet it will be about two years from now, more or less.
Of course, you will see it much sooner on their development lines, "Testing", "Unstable" and/or "Experimental".
Re:Kernel locking (Score:2, Informative)
It's not a complete removal of the BKL. There are still some drivers (and a couple of filesystems I think) that have not been converted. Selecting those in a config as a built in or standalone will re-enable the BKL. IIRC, the plan to have those corrected or obsoleted is scheduled for .38
Re:Btrfs (Score:5, Informative)
It's running on my server at home, so i hope so ; )
Ceph is really cool (Score:5, Informative)
Ceph is a really cool bit of technology. It distributes storage redundantly across multiple machines, so you can store lots and lots of data and not lose any if one of the hard drives explodes. It should distribute the load of serving that data too. You can have a network filesystem based on this already, now they've added support for virtual block devices (i.e. remote disks) over it.
If you combine that with virtualisation (the Kernel Newbies changelog mentions that there's a patch for Qemu to directly use a Ceph-based block device) then you can do magic stuff. e.g. run all your services in virtual machines with their storage hosted by Ceph. Provide a cluster of virtualisation hosts to run those VMs. If a physical box needs maintenance, live-migrate your VMs off it without stopping them, then just yoink it from the cluster - the storage will failover magically. If a physical box explodes, just boot the VMs it was running on other nodes (or, combined with some of the hot-standby features that Xen, VMware, etc have started to offer, the VMs are already running seamlessly elsewhere as soon as the primary dies). If you need more storage or more processing, add more machines to the cluster, get Ceph to balance the storage and move some VMs around.
Not everyone is going to want to run Ceph on their home network but if you have a need for any of this sort of functionality (or even just an enthusiasm for it) then it's super cool. Oh yes and Ceph can do snapshotting as well, I believe. Ace.
What's new (Score:5, Informative)
The link in the story just points to the list post announcing a new major version of the Linux kernel. Note that the changes listed in the post are for changes from the last release candidate (-rc8) and not from the last major kernel release (2.6.36). For an overview, it's better to head over to Kernel Newbies [kernelnewbies.org]. It even has a section which summarizes the "cool stuff", major features that the new kernel brings.
Interestingly, the overview appears to overlook what I believe is a major feature introduced in 2.6.37: power management for USB 3. I may have to do some more digging through the actual kernel changelogs. Maybe the change was reverted during the last few candidate releases, but I remember reading about it in H-Online [h-online.com], particularly this part:
The XHCI driver for USB 3.0 controllers now offers power management support (1, 2, 3, 4); this makes it possible to suspend and resume without temporarily having to unload the driver.
(In the original, the parenthetical numbers are links to the kernel commits.)
Power management for USB 3 would have been the most important new feature for me. Without it, you have to resort to a number of ugly hacks to hibernate or suspend a laptop or a motherboard with USB 3 enabled. (Turning off USB 3 in the BIOS is a hardware hack that allows you to bypass the software hacks.)
Re:Kernel locking (Score:5, Informative)
It's a fairly simple idea. In any place that two threads of execution (be them real threads or interrupts or whatever) could possibly access the same resource at the same time, locking must be used to ensure data integrity and proper operation of the code. The "Big Kernel Lock" is a system wide "stop the world" lock. This is a very easy way to make the code "correct" in the sense that it will work and not corrupt data. But the downside is that while this lock is held... everything else must wait. So you better not hold it for very long and while it is easy to get correct, it has pretty bad performance implications.
A better solution is a fine grained lock just for that resource, so the only threads of execution which need to wait are ones that are actually contending for that resource. The downside here is that it is much more complicated to get correct. So when implementing this, you have to be *very* careful that you got it right.
The BLK has been in the process of being removed and has been phased out of the vast majority of the kernel for a while, this change is simply enabling a build in which it doesn't even exist if you don't build any of the older drivers which don't use more fine grained locking.
Re:Kernel locking (Score:5, Informative)
The Big Kernel Lock is a Symmetric Multi Processing (SMP) construct. In order to make kernel operations atomic you lock the entire kernel. This works as a good initial locking mechanism because it's relatively easy to implement, it avoids issues like deadlocking very well.
The problem with the BKL is that it locks the entire kernel, even if processes are calling functions totally isolated from each other only one can be in the kernel at a time.
In practice the BKL hasn't been a big deal for a while now since the important (performance wise) parts of the kernel have had finer grained locking.
So It's pretty unlikely to have much effect if any on desktop users.
Re:Kernel locking (Score:5, Informative)
Nobody, especially not desktop users, will notice any change from its removal.
Re:Includes the "magic 200-line" task grouping pat (Score:4, Informative)
Re:Btrfs (Score:4, Informative)
The problem with Btrfs isn't that it doesn't work (it works fine and has for years). The problem is that it's not very fast right now (most benchmarks I've seen show it slightly behind other major file systems in most tasks), and most things don't make use of the cool things it does.
Gurus: will this affect high-SMP workstations? (Score:4, Informative)
Re:Btrfs (Score:4, Informative)
Compared to zfs, which is the only other quasi-mainstream filesystem that has copy-on-write (which gives snapshots for free) and data checksums, btrfs is almost always faster. Most of btrfs's slowness is due to those two features. Comparing ext4 speed to btrfs speed is not fair unless you disable both with -o nodatacow.
http://www.phoronix.com/scan.php?page=article&item=btrfs_zfs_ssd&num=1 [phoronix.com]
see page 4 for btrfs random write performance, which blows away both zfs and ext4 on hdds.
Without COW and checksumming, btrfs is closer to ext4. Even so, except for applications that are reading or writing massive amounts of data, I'd rather have data integrity and SSD wear leveling and free read-only snapshots instead of maximum speed.