LinuxCon + CloudOpen + ELC-E Europe 2014

Previous presentations on Persistent Memory have focused on the challenges that arise when providing raw access to the PM. This presentation focuses on the challenges facing user programs when they try to use PM. Matthew will review some of the difficulties in using mmaped storage (whether backed by PM or a regular file), and present some best practices and solutions included in the NVM Library.

ACPI was introduced when hardware compatibility with the IBM PC became insufficient to maintain the PC ecosystem. It allowed a single binary OS image to run on various platforms using the same CPU architecture, but not exactly hardware-compatible with one another. Today, Device Trees are used to address the same platform fragmentation problem in the ARM ecosystem. Of course, there are differences between ACPI and DT. Unlike DT, ACPI had a difficulty with passing arbitrary data to the OS, but that limitation is now being removed. With ACPI now able to provide the same data as DT, a need has arisen for a shared firmware-interface-agnostic specification of hardware properties. Similarly, the platform firmware interface access for device drivers in the OS should be unified, so the same driver can work equally well on systems with ACPI or DT. I will discuss work toward that goal in Linux.

In NUMA systems, each CPU has its own bank of memory, resulting in fast access to local memory, and slower access to memory elsewhere in the system. Recently a mechanism has been implemented in the Linux kernel to automatically run programs near their memory, and to move memory to near the programs using it. This presentation explains why computers are built this way, why NUMA locality matters, how the automatic NUMA balancing kernel code works, what it can do, and what kind of performance improvements have been observed. This presentation is also a good opportunity to discuss recent and future developments for the automatic NUMA balancing code.

The Linux kernel-user-space API is littered with design errors: APIs that are non-extensibe, unmaintainable, overly complex, limited-purpose, violations of standards, and inconsistent. Most of those mistakes can't be fixed because doing so would break the ABI that the kernel presents to user-space binaries. To further rub salt into the wound, kernel-user-space APIs are often buggy when first shipped.

Thus, it's important to get API designs right the first time. Taking (good and bad) examples from past APIs, I'll cover a number ideas on improving the design of future kernel user-space APIs. Those tips are relevant both for kernel developers producing the APIs and for user-space programmers looking at what kernel developers are serving to them. I'll also look at some strategies that developers can pursue in order to get help with improving the designs of APIs that they are producing.

Recently storage vendors have advocated 'shingled media recording' devices. These drives are estimated to provide larger capacity than existing drives, but at the same time introduce a new access model. Hence it will not be possible to use them as all-purpose drives without modifications to the storage stack. For Linux there are two different proposals for handling these devices, either by using modified filesystems or by adding a device-mapper module.
This talk gives an overview about the technology behind shingled media recording and the proposed changes to the linux storage stack.
I will also present the results from running a modified stack on a pre-production device and its implications for further development.

Why is my network slow? This is the most common user complaint in both
home and enterprise environments. Many of these problems are caused
by queuing problems in the network.

This talk will show some of the solutions developed, demonstrate how
they work, and identify where more work still needs to be done. The
demonstrations use the analogy of fluid dynamics to explain CoDel,
PIE, and other smart queuing mechanisms.

The talk presents a method to extend coverage of existing tests by systematic and targeted fault injection in Linux kernel. The method is developed within Linux File System Verification project that aims to provide an exhaustive test suite for Linux file system drivers.

The presented method of fault injection allows to systematically simulate faults dedicated to a file system driver under test (faults of memory allocation requests, bio layer, etc.). That means it does not introduce faults into requests coming from other modules and it implements systematic iteration of fault situations versus a prevailing random approach.

The talk presents results of experiments with the method, defines requirements to tests so they can be used with the method and discusses lessons learnt so far.