Linux Kernel 3.12 Released

Linus Torvalds has announced the release of Linux Kernel 3.12:

I was vacillating whether to do an rc8 or just cut the final 3.12, but since the biggest reason to *not* do a final release was not so much the state of the code, as simply the fact that I’ll be traveling with very bad internet connection next week, I didn’t really want to delay the release. Sure, we had a number of driver reverts, and there was an annoying auto-NUMA memory corruption fix series, but none of it was really worth delaying 3.12 for.

But the fact that I’m going to be (effectively) off-line next week means that I’m *not* opening the merge window for 3.13 yet – since I won’t have the bandwidth to really do merges anyway.

That doesn’t mean that you can’t send me pull request for the merge window early, of course – maintainers can *always* send their pull requests early rather than late, if they have everything lined up and ready. But if you have some feature that still wants polishing, you basically get a free week to do that.

So the two-week merge window for 3.13 will start a week from now. You have an extra week. But that also means that I will be doubly disappointed in anybody who then leaves their merge request until the *end* of that two-week merge window.

Anyway..

Onto a totally different topic: we’re getting to release numbers where I have to take off my socks to count that high again. I’m ok with 3.<low teens>, but I don’t want us to get to the kinds of crazy numbers we had in the 2.x series, so at some point we’re going to cut over from 3.x to 4.x, just to keep the numbers small and easy to remember. We’re not there yet, but I would actually prefer to not go into the twenties, so I can see it happening in a year or so, and we’ll have 4.0 follow 3.19 or something like that.

Now, it’s just a number (since we’ve long since given up on feature-related releases), and it’s at least a year away, so why do I even mention it at all?

The reason I mention it is because I’ve been mulling over something Dirk Hohndel said during LinuxCon EU and the kernel summit. He asked at the Q&A session whether we could do a release with just stability and bug-fixes, and I pooh-poohed it because I didn’t see most of us having the attention span required for that (cough*cough*moronic*woodland creature*cough*cough).

So I may be pessimistic, but I’d expect many developers would go “Let’s hunt bugs.. Wait. Oooh, shiny” and go off doing some new feature after all instead. Or just take that release off.

But I do wonder.. Maybe it would be possible, and I’m just unfairly projecting my own inner squirrel onto other kernel developers. If we have enough heads-up that people *know* that for one release (and companies/managers know that too) the only patches that get accepted are the kind that fix bugs, maybe people really would have sufficient attention span that it could work.

And the reason I mention “4.0” is that it would be a lovely time to do that. Roughly a years heads-up that “ok, after 3.19 (or whatever), we’re doing a release with *just* fixes, and then that becomes 4.0″.

Comments?

That means Linux 4.0 should be released next year, and the last 3.x release (3.19?) might only consists of bug fixes.

But back to the current release and the key changes made in Linux 3.12:

• Offline data deduplication support in Btrfs – Deduplication consists in removing copies of repeated data in the filesystem, since the data is the same only one copy is necessary. In some particular workloads, like virtualization VMs – which often contain similar copies of operating systems – the gains can be enormous. By “offline”, it means that the deduplication process is done when the file system is mounted and running, but it’s not done automatically and transparently as processes write data, but rather it’s triggered by userspace software at a time controlled by the system administrator. Online deduplication will be added in future releases.bedup and duperemove tools respectively for deduplication, and deduping, can be found here and here.
• Graphic performance boost for AMD Radeon hardware – No major change in Radeon drier, but the ondemand governor was oscillating too much between frequencies, and this oscillation harmed graphic performance for Radeon GPUs. The new algorithm added a better frequency algorithm that eliminates this problem. See benchmark results on Phoronix between 3.12 and previous kernel version.
• Automatic GPU switching in laptops with dual GPUs –  Some laptop hardware, like Nvidia Optimus, have two GPUs, one optimized for performance and other for power saving. Until now, some hacks have been needed to switch between these GPUs. In this release, the driver handles the switch automatically
• Separate devices nodes for graphics mode setting and rendering – Recent hardware development (especially on ARM) shows that rendering (via GPU) and mode-setting (via display-controller) are not necessarily bound to the same graphics device. This release incorporates in the graphics layer support for separate device nodes for mode setting and rendering. The main usage is to allow different access-modes for graphics-compositors (which require the modeset API) and client-side rendering or GPGPU-users (which both require the rendering API). For more information, see this blog post: Splitting DRM and KMS device nodes
• Improved timerless multitasking: allow timekeeping CPU go idle – Linux 3.10 added support for timerless multitasking. This support, however, had a caveat: it could turn off interrupts in all CPUs, except one that is used to track timer information for the other CPUs. But that CPU keeps the timer turned on even if all the CPUs are idle, which was useless. This release allows to disable the timer for the timekeeping CPU when all CPUs are idle.
• RAID5 multithreading – This release attempts to spread the work needed to handle raid 5 stripes to multiple CPUs in the MD (“multiple devices”) layer, which allows more IO/sec on fast (SSD) devices.
• Improved locking performance for virtualized guests – The operating system that runs in each virtualized guest also runs its own locks. With some locks, like spinning locks, this causes problems when many guests are present and keep spinning and wasting host CPU time and other problems. This release replaces paravirtualized spinlocks with paravirtualized ticket spinlocks, which have better performance properties for virtualized guests and brings speedups on various benchmarks. Read Prevent Guests from Spinning Around for more information.
• New lockref locking scheme, VFS locking improvements – This release adds a new locking scheme, called “lockref”. The “lockref” structure is a combination “spinlock and reference count” that allows optimized reference count accesses. This allows to avoid the nastiest cases of spinlock contention on large machines. When updating the reference counts on a large system, it will still end up with the cache line bouncing around, but that’s much less noticeable than actually having to spin waiting for the lock. This release already uses lockref to improve the scalability of heavy pathname lookup in large systems. Recommended LWN article: Introducing lockrefs
• Better Out-Of-Memory handling – The Out-Of-Memory state happens when the computer runs out of RAM and swap memory. When Linux gets into this state, it kills a process in order to free memory. This release includes important changes to how the Out-Of-Memory states are handled, the number of out of memory errors sent to userspace and reliability. For more details see Reliable out-of-memory handling.
• XFS directory recursion scalability, namespace support – XFS has added support for a directory entry file type, the purpose is that readdir can return the type of the inode the dirent points to to userspace without first having to read the inode off disk. Performance of directory recursion is much improved. Parallel walk of ~50 million directory entries across hundreds of directories improves significantly, from roughly 500 getdents() calls per second and 250,000 inode lookups per second to determine the inode type at roughly 17,000 read IOPS to 3500 getdents() calls per second at 16,000 IOPS, with no inode lookups at all.This release has also added XFS support for namespaces, and has reincorporated defragmentation support for the new CRC filesystem format.

Further details on Linux 3.12 are available on Kernelnewbies.org.

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress