|
|
Subscribe / Log in / New account

4.8 Merge window part 2

By Jonathan Corbet
August 3, 2016
As of this writing, Linus has pulled 10,589 non-merge changesets into the mainline repository; that is 7,433 since last week's summary. Clearly it has been a busy week. As is often the case, much of the work being merged takes the form of internal improvements that are not immediately visible to kernel users, but a number of interesting features have found their way in as well.

Some of the more significant user-visible features include:

  • The arm64 architecture has gained support for the kexec mechanism (allowing one kernel to boot directly into another) and kernel probes.

  • The TCP "New Vegas" congestion-control algorithm is now supported. New Vegas is a significant update to Vegas, adding better support for data-center settings in particular. See this document for details.

  • The mac80211 ("WiFi") layer has seen some interesting congestion-control changes. Normal queuing disciplines interact poorly with the frame aggregation mechanism used by wireless protocols, leading to poor performance, so the queuing discipline code has been disabled for mac80211. Instead, the mac80211 layer is now using the CoDel fair-queuing algorithm. This should be a significant step forward for better WiFi performance on Linux.

  • The reliable datagram sockets (RDS) protocol allows the creation of datagram-oriented connections over a TCP link. In 4.8, the RDS implementation can use multiple TCP connections to support RDS routing between two hosts, greatly increasing the maximum throughput. See this changelog for some details and a discussion of how this protocol differs from multipath TCP.

  • The "express data path" (XDP) work described in this article has moved forward. In 4.8, network drivers can define a hook allowing a BPF program to be loaded; that program will run on incoming packets before they even have internal data structures set up for them. The hook can indicate that packets should be dropped, but it also has the ability to do simple rewriting and forwarding. For some types of workloads, the result can be greatly increased performance without the need for kernel bypass techniques.

  • The kernel's pseudo-random number generator has been replaced with a new implementation using the ChaCha20 stream cipher. There have also been some changes made to address scalability problems when user-space programs are consuming massive amounts of random data.

  • The memory-management subsystem's page-reclaim mechanism has been fundamentally reworked to track pages based on NUMA nodes rather than on memory zones. As Mel Gorman noted in the patch posting, zone-based reclaim was important in the days of 32-bit systems with a lot of high memory but, now that large-memory systems are mostly running 64-bit kernels, node-based reclaim is a more suitable approach. Users should see little change beyond, hopefully, better performance; see the posting for a number of benchmark results.

  • A fair amount of work has been put in toward the goal of allowing unprivileged users to mount filesystems in user namespaces. That goal still depends on a number of remaining loose ends being addressed, though, and so will not be achieved in the 4.8 development cycle.

  • The kernel has gained support for the Common Architecture Label IPv6 Security Option (CALIPSO) standard. CALIPSO can be used to attach security labels to packets, making them subject to normal (SELinux or Smack) security policies.

  • The PowerPC64 architecture now has a just-in-time compiler for BPF programs.

  • New hardware support includes:

    • Processors and systems: Artesyn MVME7100 single-board computers, R-Car V2H (R8A7792) systems-on-chip (SoCs), and Broadcom BCM23550 SoCs.

    • Audio: Analog Devices ADAU7002 Stereo PDM-to-I2S/TDM converters, Cirrus Logic CS53L30 and CS35L33 codecs, Maxim MAX9860 mono audio voice codecs, Maxim MAX98504 speaker amplifiers, and Allwinner A10 I2S audio interfaces.

    • Graphics: ARM Mali display processors, Silicon Image sii902x RGB/HDMI bridges, and Toshiba TC358767 eDP bridges.

    • Input: Atmel capacitive touch buttons, Ntrig/Microsoft Surface 3 SPI touchscreens, Raydium I2C touchscreens, Pegasus Mobile Notetaker Pen input tablets, and Alps I2C HID touchpads and StickPointers.

    • Miscellaneous: TI LP3952 2 channel LED controllers, Qualcomm Hexagon V5 peripheral image loaders, Marvell version 2 XOR engines, Xilinx ZynqMP DMA engines, R-Car R8A7796 clock pulse generators, Allwinner H3 clock-control units, AmLogic S905 clock controllers, PowerPC PowerNV PCI hotplug controllers, Aspeed 2400 watchdog timers, Maxim Max77620 watchdog timers, Amlogic Meson GXBB SoCs watchdog timers, Broadcom STB SDIO/SD/MMC host controllers, Broadcom PDC mailbox managers, Altera Arria10 DevKit system resource chips, Atmel external bus interface controllers, NVIDIA Tegra ACONNECT bus controllers, HiSilicon SPI-NOR flash controllers, MediaTek SDG1 NFC nand controllers, Atmel Quad SPI controllers, Cadence Quad SPI controllers, and Aardvark PCIe controllers.

    • Networking: Freescale QUICC Engine HDLC controllers, Broadcom BCM53xx Ethernet switches, Broadcom Northstar2 PCIe PHYs, Intel XWAY PHYs, Renesas R-Car CAN FD controllers, Hisilicon fast Ethernet MAC controllers, and APM X-Gene SoC MDIO bus controllers.

    • Pin control: Oxford Semiconductor OXNAS SoC family pin controllers, Maxim MAX77620/MAX20024 pin controllers, UniPhier PH1-LD11 and PH1-LD20 SoC pin controllers, Intel Merrifield pin controllers, Broadcom NSP pin controllers, Qualcomm 9615 pin controllers, and STMicroelectronics STM32F746 pin controllers.

Changes visible to kernel developers include:

  • The GCC plugin infrastructure patches have been merged, making it possible to use plugin modules to the compiler to modify how the kernel is built. As of this writing, plugins for coverage testing and calculation of cyclomatic complexity have been merged. The "latent entropy" plugin, which tries to generate entropy early in the bootstrap process, is in a pull request but has not been pulled as of this writing.

  • The new skb_array mechanism adds an array-based FIFO data structure for the queuing of network packets; see <linux/skb_array.h> for an overview of the API.

  • The task of reworking the CPU hotplug mechanism continues with the conversion of more notifiers to the new scheme. As Thomas Gleixner put it in the pull request: "Another 700 hundred line of unpenetrable maze gone".

The 4.8 merge window still has a few days to run, so expect a few more features to land before the 4.8-rc1 release comes out. Next week's Kernel Page will, of course, contain an update with the final changes to be merged for this development cycle.

Index entries for this article
KernelReleases/4.8


to post comments

4.8 Merge window part 2

Posted Aug 4, 2016 2:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> The hook can indicate that packets should be dropped, but it also has the ability to do simple rewriting and forwarding. For some types of workloads, the result can be greatly increased performance without the need for kernel bypass techniques.
Anybody want to bet when we will see full scale luajit or JS VM in the kernel?

4.8 Merge window part 2

Posted Aug 4, 2016 7:53 UTC (Thu) by gdt (subscriber, #6284) [Link] (1 responses)

It's a concern because the kernel and networking hardware are using different-but-similar technologies to do the same thing: the kernel using BPF extensions and networking hardware using P4. At some point it will be desirable to run P4 within the kernel -- so the same systems can provision on-hardware networking and on-host networking. Hopefully later integration of P4 into the kernel will be possible, rather than being rejected for feature duplication.

4.8 Merge window part 2

Posted Aug 4, 2016 9:36 UTC (Thu) by paulj (subscriber, #341) [Link]

P4 is a much more high-level language than BPF though. P4 tends to be compiled to something else that is synthesisable to hardware or JITable. Indeed, don't the P4 tools come with something to transform it to BPF?

It is unfortunate though that there's split between the hardware world and the software world on how fast packet filter+action processes should be specified. Sigh.

4.8 Merge window part 2

Posted Aug 5, 2016 10:03 UTC (Fri) by cavok (subscriber, #33216) [Link] (2 responses)

Do we have any ARM MALI GPU support in the kernel now? Doesn't it call for an article on its own?

4.8 Merge window part 2

Posted Aug 5, 2016 10:26 UTC (Fri) by farnz (subscriber, #17727) [Link] (1 responses)

It's not that exciting, unfortunately - it's just support for the Mali display controller, whose job is to take a framebuffer in memory and pump it through a connector to a display.

4.8 Merge window part 2

Posted Aug 5, 2016 13:47 UTC (Fri) by excors (subscriber, #95769) [Link]

To be fair, its job is slightly more interesting than that - it can composite multiple layers with alpha blending, rotation, scaling, colour conversion, etc, on the fly as it's pumping lines out to the display.

Still almost completely unrelated to the Mali GPU, though. And the Mali Video processors. And the country of Mali. Maybe not the most unambiguous of brand names...

4.8 Merge window part 2

Posted Aug 5, 2016 13:49 UTC (Fri) by bbockelm (subscriber, #71069) [Link] (2 responses)

> A fair amount of work has been put in toward the goal of allowing unprivileged users to mount filesystems in user namespaces ...

Have any further information or links on the subject? I was recently bemoaning my inability to do precisely this a few days back and would be interested in the big picture of what the developers would like to do (overlayfs? ext3 / loopback? Read/write or read-only? Security concerns? Etc).

4.8 Merge window part 2

Posted Aug 6, 2016 12:47 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (1 responses)

Usually I see such things in the list of interesting development branches at the bottom of the Kernel page. There doesn't seem to be a link for this branch though.

Unprivileged mount patches

Posted Aug 6, 2016 13:50 UTC (Sat) by corbet (editor, #1) [Link]

You just have to look during the right week. See this patch set, for example.


Copyright © 2016, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds