Open Source Summit North America 2017

The kernel development community has dealt with a number of scalability crises over the years as it has grown into one of the largest software-development projects on the planet. We have not had a serious scalability issue for over a decade, but there may be another one sooner than many expect. This talk will point out the places where the process is under stress and contemplate what can be done to improve the situation.

The Linux project's email-based reviewing process is highly effective in filtering open source contributions on their way from mailing list discussions towards Linus' Git repository. However, once integrated, it is difficult to link Git commits back to their review comments in mailing list discussions, especially when considering commits that underwent multiple versions (and hence review rounds), that belonged to multi-patch series or that were cherry-picked. email2git is a plugin on top of the cregit platform (https://cregit.linuxsources.org/) that uses different algorithms to match review emails to Git commits, then enables clicking on a particular token in a source code file to obtain links to relevant email discussions about the commit that introduced this token. Understanding the context of commits is helpful for new contributors to understand existing code, new maintainers in a subsystem to understand the rationale of older commits, and security experts in to understand the context around code where a vulnerability has been detected.

Advanced performance observability and debugging have arrived built into the Linux 4.x series, thanks to enhancements to Berkeley Packet Filter (BPF, or eBPF) and the repurposing of its sandboxed virtual machine to provide programmatic capabilities to system tracing. Netflix has been investigating its use for new observability tools, monitoring, security uses, and more. This talk will be a dive deep on these new tracing, observability, and debugging capabilities, which sooner or later will be available to everyone who uses Linux. Whether you’re doing analysis over an ssh session, or via a monitoring GUI, BPF can be used to provide an efficient, custom, and deep level of detail into system and application performance.

This talk will also demonstrate the new open source tools that have been developed, which make use of kernel- and user-level dynamic tracing (kprobes and uprobes), and kernel- and user-level static tracing (tracepoints). These tools provide new insights for file system and storage performance, CPU scheduler performance, TCP performance, and a whole lot more. This is a major turning point for Linux systems engineering, as custom advanced performance instrumentation can be used safely in production environments, powering a new generation of tools and visualizations.

Linux support for huge pages has been around since the early 2.6 time frame. When support was added, it followed the 'everything is a file' model and the result was hugetlbfs. hugetlbfs represents a pool of huge pages that are best pre-allocated at boot time. Because of this need for pre-allocation, special management and (minimal) application code modification, few applications actually use hugetlbfs. The early adopters and most prominent current users of hugetlbfs are large databases. Databases like to control as much of the system as possible and may even enjoy the extra control that hugetlbfs provides.

Recent efforts in the area of huge page support have been centered around Transparent Huge Pages(THP), where recent patches have added page cache support, and work is underway to even add support to the ext4 filesystem. With THP's ease of use, one would think that few people care about the older and more difficult to manage hugetlbfs. However, some new features have been added to hugetlbfs mostly at the request of database developers. Surprisingly, some of these new features have found successful use in other areas such as Qemu Post Copy Live Migration.

This talk will discuss the new hugetlbfs features. In addition, it will include a general hugetlbfs presentation. At this year's LSF/MM summit it was noted that hugetlbfs is "its own vm". In a sense, it is true. Within the mm subsystem, there are many places that have code such as:
if (hugetlbpage())
call special hugetlbfs code
else
process normally

Therefore, some assumptions one makes about general Linux mm do not apply to hugetlbfs. Some of the most prominent differences will be presented.

The goal for this presentation is to expose more people to this often forgotten functionality so that perhaps it can be employed in more creative ways.

The deadline scheduler adds the ability of scheduling tasks, not according to a fixed priority, but according to a dynamic priority, based on the task’s deadline. To be able to use this scheduler, a task needs to inform three parameters: the period, the runtime, and the relative deadline.

Using these parameters, the scheduler tries to provide the runtime CPU time, at each period for each deadline task. Under the perfect conditions, the sched deadline is able to schedule all tasks within their deadline, providing the timing guarantee real-time tasks need. Did you notice the under the perfect conditions part? The conditions are:

- Implicit deadline tasks – or constrained being quite a pessimist.
- Tasks should not self-suspend;
- All the system’s delay must be taken into account.
- The runtime must represent the worst-case execution time;
- The system should not be overload – which requires some very restrictive setup.

All these restrictions open the opportunity for improvements in the deadline scheduler. This presentation aims to list these points of improvement, point directions and challenges. Such as:

- Constrained deadline tasks guarantees
- Arbitrary affinity tasks
- Hierarchical scheduling – RT Throttling
- Tracepoints
- Precise way to define task’s runtime
- Other possibilities for admission tests

There are many points of improvement in the deadline scheduler, and discussing them is fundamental for a wider and safer adoption of this powerful scheduler.

First, a few words about what this talk is not. It is not a tutorial on how to program quantum computers. For that, you should find a D-Wave machine or go to http://research.ibm.com/ibm-q/, either of which should provide an excellent hands-on introduction to the current practice of quantum computing. Either way, highly recommended!

This talk instead gives an overview of the current state and trends of quantum-computing technology. It then uses these trends to make some educated guesses about the challenges facing the use of quantum computing in production. Of course, the bigger the killer app, the more effort will be invested in overcoming these challenges. This talk therefore also gives an overview of quantum computing’s most likely killer apps. This will lead into some possibilities of how quantum computing might affect the Linux plumbing, and vice versa. The talk will conclude with the usual free advice, which will be worth every penny that you pay for it.