|
|
Subscribe / Log in / New account

3.14 Merge window part 2

By Jonathan Corbet
January 29, 2014
As of this writing, almost 8,600 non-merge changesets have been pulled into the mainline repository for the 3.14 development cycle — 5,300 since last week's merge window summary. As can be seen from the list below, quite a bit of new functionality has been added to the kernel in the last week. Some of the more significant, user-visible changes merged include:

  • The event triggers feature has been added to the tracing subsystem. See this commit for some information on how to use this feature.

  • The user-space probes (uprobes) subsystem has gained support for a number of "fetch methods" providing access to data on the stack, from process memory, and more. See the patchset posting for more information.

  • The Xen paravirtualization subsystem has gained support for a "paravirtualization in an HVM container" (PVH) mode which makes better use of hardware virtualization extensions to speed various operations (page table updates, for example).

  • The ARM architecture can be configured to protect kernel module text and read-only data from modification or execution. The help text for this feature notes that it may interfere with dynamic tracing.

  • The new SIOCGHWTSTAMP network ioctl() command allows an application to retrieve the current hardware timestamping configuration without changing it.

  • "TCP autocorking" is a new networking feature that will delay small data transmissions in the hope of coalescing them into larger packets. The result can be better CPU and network utilization. The new tcp_autocorking sysctl knob can be used to turn off this feature, which is on by default.

  • The Bluetooth Low Energy support now handles connection-oriented channels, increasing the number of protocols that can work over the LE mode. 6LoWPAN emulation support is also now available for Bluetooth LE devices.

  • The Berkeley Packet Filter subsystem has acquired a couple of new user-space tools: a debugger and a simple assembler. See the newly updated Documentation/networking/filter.txt for more information.

  • The new "heavy-hitter filter" queuing discipline tries to distinguish small network flows from the big ones, prioritizing the former. This commit has some details.

  • The "Proportional Integral controller Enhanced" (PIE) packet scheduler is aimed at eliminating bufferbloat problems. See this commit for more information.

  • The xtensa architecture code has gained support for multiprocessor systems.

  • The Ceph distributed filesystem now has support for access control lists.

  • New hardware support includes:

    • Processors and systems: Marvell Berlin systems-on-chip (SoCs), Energy Micro EFM32 SoCs, MOXA ART SoCs, Freescale i.MX50 processors, Hisilicon Hi36xx/Hi37xx processors, Snapdragon 800 MSM8974 SoCs, Systems based on the ARM "Trusted Foundations" secure monitor, Freescale TWR-P102x PowerPC boards, and Motorola/Emerson MVME5100 single board computers.

    • Clocks: Allwinner sun4i/sun7i realtime clocks (RTCs), Intersil ISL12057 RTCs, Silicon Labs 5351A/B/C programmable clock generators, Qualcomm MSM8660, MSM8960, and MSM8974 clock controllers, and Haoyu Microelectronics HYM8563 RTCs.

    • Miscellaneous: AMD cryptographic coprocessors, Freescale MXS DCP cryptographic coprocessors (replacement for an older, unmaintained driver), OpenCores VGA/LCD core 2.0 framebuffers, generic GPIO-connected beepers, Cisco Virtual Interface InfiniBand cards, Active-Semi act8865 voltage regulators, Maxim 14577 voltage regulators, Broadcom BCM63XX HS SPI controllers, and Atmel pulse width modulation controllers.

    • Multimedia Card (MMC): Arasan SDHCI controllers and Synopsys DesignWare interfaces on Hisilicon K3 SoCs.

    • Networking: Marvell 8897 WiFi and near-field communications (NFC) interfaces, Intel XL710 X710 Virtual Function Ethernet controllers, and Realtek RTL8153 Ethernet adapters.

    Note also that the AIC7xxx SCSI driver, deprecated since the 2.4 days, has finally been removed from the kernel.

Changes visible to kernel developers include:

  • The ARM architecture code can be configured to create a file (kernel_page_tables) in the debugfs filesystem where the layout of the kernel's page tables can be examined.

  • The checkpatch script will now complain about memory allocations using the __GFP_NOFAIL flag.

  • There is a new low-level library for computing hash values in situations where speed is more important than the quality of the hash; see this commit for details.

At this point, the 3.14 merge window appears to be winding down. If the usual two-week standard applies, the window should stay open through February 2, but Linus has made it clear in the past that the window can close earlier if he sees fit. Either way, next week's Kernel Page will include a summary of the final changes pulled for this development cycle.

Index entries for this article
KernelReleases/3.14


to post comments

3.14 Merge window part 2

Posted Jan 30, 2014 3:26 UTC (Thu) by dlang (guest, #313) [Link] (4 responses)

thanks for the note on TCP autocorking, this is a sysctl item that I will need to remember to set by default from now on.

If the system is idle, what does it hurt to send small packets. If it's busy and small packets start to clog things up, the packets will end up getting consolidated anyway.

3.14 Merge window part 2

Posted Jan 30, 2014 4:13 UTC (Thu) by Aliasundercover (subscriber, #69009) [Link] (3 responses)

I frequently turn the Nagle algorithm off with setsockopt(... TCP_NODELAY ...) when dealing time sensitive communications between machines in automation. I wonder if TCP autocorking will mean I need to tweak another knob. I certainly hope not.

3.14 Merge window part 2

Posted Jan 30, 2014 9:16 UTC (Thu) by cwillu (guest, #67268) [Link] (2 responses)

> tcp_autocorking - BOOLEAN
> Enable TCP auto corking :
> When applications do consecutive small write()/sendmsg() system calls,
> we try to coalesce these small writes as much as possible, to lower
> total amount of sent packets. This is done if at least one prior
> packet for the flow is waiting in Qdisc queues or device transmit
> queue. Applications can still use TCP_CORK for optimal behavior
> when they know how/when to uncork their sockets.
> Default : 1

I read this as saying that corking will only happen if you already had packets waiting in the outgoing buffer anyway.

> * Because TX completion will happen shortly, it gives a chance
> * to coalesce future sendmsg() payload into this skb, without
> * need for a timer, and with no latency trade off.

3.14 Merge window part 2

Posted Jan 30, 2014 10:25 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

if there are already packets waiting in the outgoing buffer, won't that delay the sending of the packets so they can be consolidated anyway? so why would auto-corking be needed?

3.14 Merge window part 2

Posted Feb 13, 2014 16:30 UTC (Thu) by Jan_Zerebecki (guest, #70319) [Link]

Handing off a new packet for transmission (uncork) can be delayed without delaying transmission of another packet that was already handed off.


Copyright © 2014, 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