What better way to kick off the new year than with a brand new kernel, fresh out of Kernel.org? Linus Torvalds released the 3.2 kernel on January 4th, with improvements in the Ext4 and Btrfs filesystems, thin provisioning features, a new architecture, and CPU bandwidth control.
The last major kernel release was in late October of last year. That release, if you recall, included support for OpenRISC, Near-Field Communications, and the cpupowerutils project.
Last week, Torvalds pushed 3.2 out into the world with a pretty short announcement and opened the merge window for Linux 3.3. Naturally, this release has the usual fixes and new drivers, but also some notable new features that are worth taking a look at.
Filesystem Improvements
Let’s face it, users have an insatiable desire for more and more storage. Which means larger and larger hard drives. Unfortunately, the maximum filesystem block for Ext4 systems has been stuck at 4KB, which is a bit of an inconvenience for users who are working primarily with larger files. With the 3.2 release, users can increase the block size to a maximum of 1MB.
Btrfs has seen a fair number of small improvements with 3.2 as well. For example, Btrfs now gives more detailed messages when it encounters bad blocks or other errors. In addition, you can now do a manual inspection of the filesystem, so you can query Btrfs about what files belong to bad blocks.
Hexagon and Other Improvements
Linux adding a new architecture is not unusual, but the Hexagon Processor from Qualcomm is a bit different. Most of the CPUs supported by Linux are like the x86/AMD64 architecture that most of us use in our desktop/laptop machines or servers. (“Like,” in that they are for a wide range of general purpose machines.)
The Hexagon is a “general-purpose digital signal processor designed for high performance and low power.” It can be used for things like processing video, or could be used for the OS and digital signal processing. You probably won’t be running Linux Mint on this one anytime soon, but it might be in your next set-top box or something else that requires a lot of processing power for media but not general purpose computing.
On the TCP side, Google really wants to get search results to you a bit faster. So much so, in fact, that they have developed a better packet recovery algorithm for TCP. Google’s algorithm, “Proportional Rate Reduction,” is meant to improve latency.
CPU Bandwidth Control and Thin Provisioning
As time goes on, the Linux kernel just gets more and more flexible when it comes to fine-tuning resource control. The 3.2 kernel has two notable features that will be very useful in this regard.
The first is the CPU bandwidth control, which allows admins to specify how much CPU time a process group can use in a period of time. For example, users could use the scheduling features to limit a group to N CPUs runtime in a specific period (measured in milliseconds), or limit groups to a fraction of a CPU. When the group hits its limit, it’s scaled back until the next time period starts.
For instance, you could give a time period of 1000ms and a quota of 1000ms. That would give a group 1 CPU worth of runtime. Or you could give the group a quota of 100ms with a time period of 1000ms, which would limit the group to 1/10th of a CPU runtime.
The second feature allows over-provisioning of storage so that space isn’t wasted. Wait, what? How is over-provisioning a good thing?
Imagine you have a system with 500 users given a storage quota of some arbitrary amount, like 15GB. You give each user the maximum amount of storage you think is reasonable or necessary, but the odds are in many cases that users will only use a fraction of the storage. For instance, in a lot of Web hosting scenarios you might provision users with 10GB of storage but in reality many users are only going to use a few hundred MB, not 10GB.
The thin provisioning features added to the Linux Device Mapper allow admins to over-provision, so you don’t have to have enough storage to cover the maximum storage scenario. This allows companies to avoid spending a lot of money on storage that they don’t need – an especially nifty feature now, considering the rising prices of hard drives.
Coming Attractions
Kernel development never sleeps, so while 3.2 is making its way out into the world kernel folks are busily hacking on 3.3 and beyond.
One of the more interesting features that we might see in 3.3 (remember, no promises) is a lot of Android integration. Greg Kroah-Hartman wrote in mid-December that “the next linux-next Linux kernel release should almost boot an Android userspace, we are only missing one piece, ashmem, and that should hopefully land in my staging-next tree next week. The patches are still being tested and cleaned up by others… hopefully, by the 3.3 kernel release, the majority of the Android code will be merged.”
That won’t mean a complete Android kernel in mainline Linux. Hartman says that there’s still more work to do, but it’s significant progress nonetheless.
By the way, if you’re into “ancient” kernels, Kroah-Hartman also released the 2.6.32.53 kernel on Friday, January 6th.
