#pragma section-numbers on #pragma keywords Linux, kernel, operating system, changes, changelog, file system, Linus Torvalds, open source, device drivers #pragma description Summary of the changes and new features merged in the Linux kernel during the 3.13 development cycle /!\ /!\ /!\ NOTE /!\ /!\ /!\ If the new kernel is released before the previous message has been removed, it means that this article isn't entirely complete. After reading it, you can satisfy your curiosity with other new sources such as * LWN list of changes [https://lwn.net/Articles/573272/ part 1], [https://lwn.net/Articles/574222/ part 2], [https://lwn.net/Articles/574965/ part 3] * German language: heise.de Kernel-Log Was 3.13 bringt [http://www.heise.de/open/artikel/Kernel-Log-Was-3-13-bringt-1-Dateisysteme-und-Storage-2062929.html (1): Dateisysteme und Storage], [http://www.heise.de/open/artikel/Kernel-Log-Was-3-13-bringt-2-Netzwerk-2066673.html (2) Netzwerk], [http://www.heise.de/open/artikel/Kernel-Log-Was-3-13-bringt-3-Infrastruktur-2070247.html (3) Infrastruktur ], [http://www.heise.de/open/artikel/Kernel-Log-Was-3-13-bringt-4-Treiber-2074253.html (4) Treiber], [http://www.heise.de/open/artikel/Kernel-Log-Was-3-13-bringt-5-Grafiktreiber-2074557.html (5) Grafiktreiber] [[TableOfContents()]] = Prominent features = == A scalable multi-queue block layer for high performance SSD storage == For decades, traditional hard disks have defined the design requirements for the block layer used in operating systems to communicate applications with the storage device drivers. With the advent of modern solid-state disks (SSD), these assumptions are becoming invalid. The Linux design employed a single coarse lock design for protecting the IO request queue, which can achieve an IO submission rate of around 800.000 IOs per second, regardless of how many cores are used to submit IOs. This was more than enought for traditional magnetic hard disks, whose IO submission rate in random accesses is only in the hundreds, but it is not enought for modern SSD disks, which can achieve a rate close to 1 million, and are improving fast in every new generation. It is also unfit for the modern multicore world. This release includes a new design for the Linux block layer. This design is based on two levels of queues: one level of per-CPU queues for submitting IO, which then funnel down into a x number of hardware submission queues. The mapping between submission queues and hardware queues might be 1:1 or N:M, depending on hardware support and configuration. Experiments shown that this design can achieve many millions of IOs per second, leveraging the new capabilities of NVM-Express or high-end PCI-E devices and multicore CPUs, while still providing the common interface and convenience features of the block layer. Paper:[http://kernel.dk/blk-mq.pdf Linux Block IO: Introducing Multi-queue SSD Access on Multi-core Systems] Recommended LWN article: [https://lwn.net/Articles/552904/ The multiqueue block layer] Code: [http://git.kernel.org/linus/320ae51feed5c2f13664aa05a76bec198967e04d (commit)] == nftables, the successor of iptables == nftables is a packet filtering framework designed to overcome existing limitations in iptables both at the functional and code design level: problems with the system update rules (very expensive when the number of rules increases which has become a problem to manage not static rules), code duplication, problematic for code maintenance and users. nftables solves these problems, while providing backwards compatibility for current iptable users. The core of the nftables design is a kernel pseudo-state machine bytecode inspired in the Berkeley Packet Filters (BPF), which provides faster lookups. A userspace utility interprets the rule-set provided by the user, it compiles it into the pseudo-state machine bytecode and then it transfers it to the kernel via the nftables Netlink's API. One of the biggest advantages of this approach is that it can replace thousands of lines of code, since you can express the packet selectors for all existing protocols using the instruction-set provided by the pseudo-state machine. It also moves most of the rest of the code to userspace. It's not neccesary a specific extension in kernel-space for each match, the userspace utility can parse a new protocol and compile it to generic bycode. As a side effect, users are likely not need to upgrade the kernel to obtain new features, they will be provided by new versions of the userspace utility and libraries. The ICMPv6 match, for example, is a "109 insertions (+) 3 deletions (-)" userspace patch. As mentioned previously, nftables provides backwards compatibility for existing iptable users. There are iptables/iptables utilities that will translate rules to nftables pseudo state-machine bytecode. It is possible to use and add new xtable modules. But these utilities also provide new features: xtables-event for reporting changes in tables/chains, better incremental rule update support (matches internal state is not lost), and ability to enable/disable the chains per table that you want. A quick how-to of the new utility and syntax is available in the "Running it" section of [https://home.regit.org/netfilter-en/nftables-quick-howto/ this page]- Recommended LWN article: [https://lwn.net/Articles/564095/ The return of nftables] Video talk about nftables: http://youtu.be/P58CCi5Hhl4 ([http://www.slideshare.net/ennael/2013-kernel-recipesnftables slides]) Project page: http://netfilter.org/projects/nftables/ == Improved performance in NUMA systems == Modern hardware with many CPUs usually have a memory controller for each CPU. While all CPUs can access to any memory direction, accessing the portions of memory addressed from a local memory controller is faster than accessing portions of memory attached to the controllers of other CPUs. This is called NUMA - "non-uniform memory architecture". Because the performance profile is different depending on the locality of the memory accesses, it's important that the operating system schedules a process to run in the same CPU where the memory it will access is mapped. The way Linux handles these situations was deficient; Linux 3.8 [http://kernelnewbies.org/Linux_3.8#head-c16d4288b51f0b50fbf615657e81b0db643fa7a0 included a new NUMA foundation] that would allow to build smarter NUMA policies in future releases. This release includes many of such policies that attempt to put a process near its memory, and can handle cases such as shared pages between processes or transparent huge pages. New sysctls have been added to enable/disable and tune the NUMA scheduling (see documentation [http://git.kernel.org/linus/10fc05d0e551146ad6feb0ab8902d28a2d3c5624 here]) Recommended LWN article: [https://lwn.net/Articles/568870/ NUMA scheduling progress] == Improved page table access scalability in hugepage workloads == The Linux kernels tracks information about each memory page in a data structure called page table. In workloads that use hugepages, the lock used to protect some parts of the table has become a lock contention. This release uses finer grained locking for these parts, improving the page table access scalability in threaded higepage workloads. For more details, see the recommended LWN article. Recommended LWN article: [https://lwn.net/Articles/568076/ Split PMD locks] Code: [http://git.kernel.org/linus/e009bb30c8df8a52a9622b616b67436b6a03a0cd (commit)], [http://git.kernel.org/linus/9491846fca57e9326b6673716c386b76fc13ebca (commit)] == Support for the High-availability Seamless Redundancy protocol == [https://en.wikipedia.org/wiki/High-availability_Seamless_Redundancy High-availability Seamless Redundancy] (HSR) is a redundancy protocol for Ethernet. It provides instant failover redundancy for such networks. It requires a special network topology where all nodes are connected in a ring (each node having two physical network interfaces). It is suited for applications that demand high availability and very short reaction time. Code: [http://git.kernel.org/linus/f421436a591d34fa5279b54a96ac07d70250cc8d (commit)] = Drivers and architectures = All the driver and architecture-specific changes can be found in the [http://kernelnewbies.org/Linux_3.13-DriversArch Linux_3.13-DriversArch page] = Core = = Memory management = = Block layer = = File systems = = Networking = = Crypto = = Virtualization = = Security = = Tracing/perf = = Other news sites that track the changes of this release = * LWN [https://lwn.net/Articles/573272/ part 1], [https://lwn.net/Articles/574222/ part 2], [https://lwn.net/Articles/574965/ part 3] * German language: heise.de Kernel-Log Was 3.13 bringt [http://www.heise.de/open/artikel/Kernel-Log-Was-3-13-bringt-1-Dateisysteme-und-Storage-2062929.html (1): Dateisysteme und Storage], [http://www.heise.de/open/artikel/Kernel-Log-Was-3-13-bringt-2-Netzwerk-2066673.html (2) Netzwerk], [http://www.heise.de/open/artikel/Kernel-Log-Was-3-13-bringt-3-Infrastruktur-2070247.html (3) Infrastruktur ], [http://www.heise.de/open/artikel/Kernel-Log-Was-3-13-bringt-4-Treiber-2074253.html (4) Treiber], [http://www.heise.de/open/artikel/Kernel-Log-Was-3-13-bringt-5-Grafiktreiber-2074557.html (5) Grafiktreiber]