What's coming in 3.10, part 2

By Jonathan Corbet
May 8, 2013

As of this writing, 10,892 non-merge changesets have been pulled into the mainline repository for the 3.10 development cycle, nearly 5,800 since last week's summary. That does not yet make 3.10 the busiest merge window ever, but chances are good that the current record holder (3.8, at 10,901 changesets) will be surpassed in the very near future. In other words, there has been a lot going on.

User-visible changes merged since last week's summary include:

The "full dynamic tick" patch set has been merged, allowing non-idle CPUs to run without the periodic timer interrupt in some situations. See this article for more information about this feature.
The TCP stack has gained support for the tail loss probe algorithm, which can speed recovery when a packet is dropped at the end of a connection. Many connections are short and latency-sensitive, so tail loss has a bigger effect than one might think. From the commit: "The TLP patch series have been extensively tested on Google Web servers. It is most effective for short Web transactions, where it reduced RTOs [retransmission timeouts] by 15% and improved HTTP response time (average by 6%, 99th percentile by 10%)."
The batman-adv mesh networking subsystem now supports "network coding," a mechanism that can, in some situations, transmit two packets to two destinations simultaneously by exclusive-ORing them together.
The TCP cookie transactions mechanism has been removed. It was never fully implemented and had a performance cost.
The IPv6 protocol is now supported over IEEE 1394 ("Firewire").
The netlink interface now supports memory-mapped I/O, eliminating the need to copy data between user and kernel space. Unsurprisingly, this involves the addition of yet another ring buffer implementation to the kernel. See Documentation/networking/netlink_mmap.txt for details.
The "single zImage" goal for the ARM architecture is getting closer; several more platforms have gained multiplatform support. The biggest holdout at this point is Samsung's Exynos, which was reverted prior to the pull request because it turned out not to be quite ready.
The XFS filesystem continues to gain checksums and other identifying information in all metadata blocks, aiding filesystem consistency checks and the cleanup process if something goes wrong. The new documentation file Documentation/filesystems/xfs-self-describing-metadata.txt has more information about this work and its goals.
The ARM multi-cluster power management patch set has been merged, clearing the way for further big.LITTLE support, including the just-posted in-kernel switcher code.
The Ceph filesystem has new support for RBD layering, essentially a mechanism for the quick creation of copy-on-write clones of filesystem snapshots.
Various tweaks to the reader/writer semaphore code have led to some impressive performance improvements for some workloads. Pgbench results improved as much as 100% in one case.
New hardware support includes:
- Boards and processors: Atmel SAMA5D3 processors, Freescale T4240 QDS and B4 QDS boards, Renesas R8A73A4, R8A7778, and R8A7790 processors, and Freescale i.MX6 DualLite/Solo processors.
- Audio: TI TAS5086 codecs and Asahi Kasei AK5386 codecs.
- Input: IMS passenger control units (in-seat controllers for airline entertainment systems).
- Miscellaneous: Samsung S3C64XX SoC pin controllers, VIA VT8500 and Wondermedia WM8xxx-series pinmux/gpio controllers, Freescale SAHARA crypto accelerators, Broadcom BCM2835 random number generators, ChromeOS embedded I2C, SPI, and keyboard controllers, Silicon Laboratories 4761/64/68 AM/FM radios, NVIDIA Tegra host1x DMA engines, Aeroflex Gaisler GRGPIO cores, TI LP5562 LED controllers, Samsung S3C, S5P and Exynos SoC PWM timers, Renesas R-Car GPIO controllers, and TI DA8xx/OMAP-L13x remote processors.
- Networking: Ralink RT5572 wireless network interfaces, Realtek RTL8188EE wireless network adapters, and Realtek RTL8152-based Ethernet adapters.
- Virtualized: CAIF link layer over virtio and QXL virtual GPUs.

Changes visible to kernel developers include:

NAPI-using network drivers that set themselves up with a weight greater than 64 will generate a user-visible warning. Larger weights can create unfairness on systems with multiple interfaces; they can also interfere with the proper functioning of the byte queue limits mechanism.
The I2C layer has a new bus arbitration module for multi-master situations and a new bus recovery infrastructure as well.
The ALSA ASoC subsystem has a new generic dmaengine_pcm driver that is able to replace a lot of platform-specific PCM implementations.
Developers wanting to tweak the randomness of "randconfig" builds can do so with the new KCONFIG_PROBABILITY environment variable.
The release() function in struct block_device_operations now returns void.
There is a new "reset controller" driver class. Reset controllers are able to force-reset another system component by way of a mechanism like a GPIO line.

A two-week merge window would close on May 13. Given the volume of code merged so far, though, it would not be at all surprising if Linus declared the end a little sooner than that.

Index entries for this article
Kernel	Releases/3.10

What's coming in 3.10, part 2

Posted May 8, 2013 23:32 UTC (Wed) by viro (subscriber, #7872) [Link]

* fairly minor: vfree() can be used in interrupt contexts now; used to require rather ugly hacks with schedule_work() et.al.

* procfs got deeviscerated^Wits guts tucked back in place. _That_ will hurt a bunch of 3rd-party drivers.
1) create_proc_entry()/create_proc_read_entry() are killed off; use proc_create().
2) struct proc_dir_entry is opaque now; use PDE_DATA(inode) for access to pde->data, proc_set_size()/proc_set_user() if you have one of the few entries that need to set ->size/->uid/->gid; consider using remove_proc_subtree() rather than keeping a lot of references to children and use proc_remove(de) if you really needed remove_proc_entry(de->parent, de->name) and can't eliminate it in saner ways.
3) if your code plays with de->count or the list of children, you are screwed; it had been racy all along and really needed killing.

Experience from the in-tree drivers was generally tolerable - the places that had been painful had serious bugs and most of the pain came from the need to deal with those.

ARM multiplatform / single zImage

Posted May 9, 2013 13:05 UTC (Thu) by arnd (subscriber, #8866) [Link]

The ARM multiplatform comment make it sound better than it really is. Exynos is the only one missing out of the ones we actually tried to get converted in 3.10, i.e. 26 out of the 34 "modern" ARMv6/v7 platforms, as well as 7 of the 36 "older" ARMv4/v5 platforms.

My hope is that we can get all the modern platforms enabled in a single kernel in 3.12, while I expect there will be only a few left over in 3.11. Qualcomm MSM, Renesas shmobile/r-mobile/r-car and Samsung S5P are likely to see only partial conversion in 3.11, the other ones should be simpler.

Among the older platforms, we have no plans to do any of the StrongARM and X-Scale based platforms, for a number of reasons all unrelated to the actual CPU core. We can probably do all the ARM720, ARM92x and PJ1 based platforms eventually, but there is no hurry as they are only compatible with other ARMv4/v5 platforms but you cannot use a common kernel together with the modern cores.