3.15 Merge window, part 2

By the time Linus released 3.15-rc1 and closed the 3.15 merge window on April 13, he had pulled 12,034 non-merge changesets into the mainline repository for this development cycle. So 3.15 does have the honor of being the busiest merge window ever, edging out 3.10, which had a mere 11,963 non-merge commits. All but the last 700 commits for 3.15 were covered in last week's merge window summary, so the list of new features added at the end of the merge window will be relatively small. Still, there are a few things worthy of note.

Faster resume

Arguably the most interesting change is a significant speedup in resume-from-suspend time on systems with SATA disk controllers. Over the years, various efforts have been made to parallelize the bootstrap and resume processes in order to reduce the wall-clock time needed to get to a working system. These attempts have often run into difficulties as the problem space proved to be more complex than originally understood. So full parallelism remains an elusive goal.

Recently, though, some developers realized that there was a piece of especially low-hanging fruit waiting to be picked: much of the time spent waiting for a system to resume goes into waiting for the ATA controllers to power up and get into a working state. Dan Williams put together a pair of patches (one to the ATA controller driver, one to the SCSI "sd" driver) to change their behavior a bit: rather than waiting for the controller to return to a working state, the drivers start the process and return immediately. That allows the rest of the kernel to continue working toward resuming the system while the controller powers up.

Of course, some of that work is likely to involve disk I/O. Any I/O requests that are submitted while the controllers are still waking up simply wait until they can be serviced. In the worst case, the system will block on I/O and fail to resume any faster than before, but, in practice, it is generally possible to get back to the window system without the need to wait for disk I/O. The results, as documented in this page describing the patches, are impressive. Resume time on a drive-heavy system dropped from 11.6 seconds to 1.1 seconds. On a couple of different single-drive systems, resume time went from over five seconds to less than one second. It is clearly a worthwhile improvement, especially since it requires little in the way of added complexity overall.

Elsewhere in the kernel

A set of patches to enable building the kernel with the LLVM compiler suite has been merged. This goal has not yet been achieved; there is another set of patches required that, possibly, will show up in 3.16. But this goal is getting closer to being achieved after some years of sporadic effort.

In a change that has a small possibility of breaking user-space code, the x86 architecture will no longer allow the creation of 16-bit segments when running in the 64-bit mode. Use of 16-bits can lead to a kernel information leak on 64-bit systems that could lead to potential security issues. Since running 16-bit code on these systems does not work all that well anyway and it's not clear that there are any users of it, this is probably a safe change to make. If users do exist, they might want to make their presence known during this development cycle so that their concerns can be addressed.

A handful of new drivers has been merged; these add support for Qualcomm SDHCI controllers, Armada 380 and 385 Marvell SoC-based SDHCI controllers, Energymicro efm32 i2c controllers, Qualcomm QUP-based I2C controllers, Cadence I2C controllers, Freescale enhanced direct memory access (eDMA) controllers, Renesas R-Car audio DMAC peripheral controllers, QCOM bus access manager (BAM) DMA controllers, Alienware AlienFX WMI-based platform features, and CPU frequency controllers on IBM POWERNV hardware,

In the 3.15-rc1 announcement, Linus let it be known that he is even less inclined than usual to add any more feature work outside of the merge window. Enough code has already found its way in to keep developers busy for the rest of the cycle, it seems. That work can be expected to be completed sometime right around the end of May if the usual pattern holds.

Index entries for this article
Kernel	Releases/3.15
Kernel	Software suspend

---

to post comments