Topics for Student Theses

Traditionally, user-space applications access device drivers through OS-provided abstractions (files, sockets, etc.). In contrast, OS-bypass technique passes a raw device directly to the user-space application, such that the device can be accessed without the OS kernel involvement. OS-bypass enables much higher request and data processing rates in contrast to the traditional socket- or file-based approaches. Frameworks, like DPDK (for network controllers) and SPDK (for NVMe controllers) are typical examples of OS-bypass technique. Unfortunately, these approaches are less flexible than traditional system-call-based device usage. For instance, passing a device to one user-space application may imply that no other application can use the same device.

As of today, OS-bypass increase flexibility through new features implemented by the devices (see RDMA-networks). Specialized devices are expensive and still maintain rigidity, as hardware is hard to change. This project aims to work around limitations of specialized hardware, by combining the flexibility of system calls with the performance of OS-bypass by developing new mechanisms for fast system calls. As a potential effect, OS-bypass may become ubiquitous for a wider range of devices. Moreover, specialized devices may gain new features without the need for hardware modifications.

The student will be presented with an architecture of a fast system call infrastructure. The student will be expected to realise the architecture, study and evaluate it. The project can be implemented for both monolithic (Linux) and a micro (L4). The student is expected to have good command in C programming and UNIX-like systems. This includes familiarity with the command line, understanding OS architecture, experience with build systems. Prior experience with kernel programming is not necessary. We offer guidance, especially with concept development, kernel programming, debugging, and scientific writing.

Supervisor: Maksym Planeta Till Miemietz

The message passing interface (MPI)1 is a de-facto standard in high-performance computing (HPC). MPI-based applications usually consist of multiple processes, which run independently from each other and periodically exchange messages for communication and synchronisation. OpenMPI2 is a wide-spread implementation of the MPI standard with a modular and well-documented codebase and UCX3 is an open-source communication framework used as a backend by OpenMPI.

The usual mode of operation in OpenMPI is to minimise communication latency by polling or busy-waiting. However, this approach leads to increased energy consumption and can reduce the overall compute performance of the system. We extended OpenMPI to, instead, block and vacate the CPU until communication finishes. The current implementation works only when a network interface is involved but not when using shared memory for communication.

The goal of this thesis is to generalise the implementation of blocking communication to incorporate both shared memory and network. To this end, the student should add blocking support to shared-memory communication in UCX re-using sychronisation primitives available in that framework.

Supervisor: Jan Bierbaum

The ATLAS scheduler1 uses metrics to predict task execution time. However, it is conceivable to use the same or a similar predictor to derive other application- and workload-related measures such as cache behavior, memory accesses, or energy consumption.

The thesis should experiment with the ATLAS predictor to analyse its ability and accuracy in predicting these other measures.

[1] Michael Roitzsch, Stefan Wächtler, Hermann Härtig: ATLAS – Look-Ahead Scheduling Using Workload Metrics. RTAS 2013, https://os.inf.tu-dresden.de/papers_ps/rtas2013-mroi-atlas.pdf

Supervisor: Michael Roitzsch, Till Smejkal, Jan Bierbaum

The K2 I/O scheduler1 was developed at the operating systems group with the goal of isolating disk accesses of low-latency applications from interference by high-bandwidth applications, specifically on modern NVMe drives. Modern NVMe drives achieve their high bandwidth by having multiple disk accesses in flight concurrently. As a downside, any request may be delayed because the drive's firmware deems that request inopportune and postpones request fulfilment, thereby causing latency-spikes for some requests.

K2 mitigates this drive-internal scheduling by limiting the amount of concurrent requests that are issued to the drive. However, limiting the requests in flight impacts total bandwidth and fairness negatively. Currently the number of requests that can be in flight is a static, tunable parameter of the K2 I/O scheduler. Non-real-time background requests can be starved.

The goal of this task is to devise a mechanism that allows queue length and request fairness to be controlled at runtime. Additionally, at least one policy to update the queue length value should be devised.

Supervisor: Michael Roitzsch, Till Miemietz

Applications in high-performance computing (HPC) usually comprise multiple processes that follow the bulk synchronous parallel (BSP)1 model: During its runtime, each process alternates between phases of independent, parallel computation and phases of communication and synchronisation. Due to the synchronisation phases, a single slow process (straggler) can delay the whole computation. So BSP simplifies programming at the expense of overall performance and system utilisation.

The ATLAS scheduler2 uses metrics to predict the execution time of applications. A metric is any value from the application domain that correlates with the amount of work to be performed. Using this predictor with an HPC application may allow to identify stragglers in advance. With this information we can either assign more (performant) compute resource to these slow processes or save energy by slowing down other processes.

In this thesis, the ATLAS predictor should be integrated with one or two simple HPC applications, e.g. from the NAS Parallel Benchmarks3. The student should identify suitable metrics within the application(s) and evaluate the prediction accuracy.

Supervisor: Jan Bierbaum

The Trusted Platform Module (TPM) is an established and widely available system component to implement Trusted Computing Concepts such as Authenticated Booting, Sealed Memory, and Remote Attestation. TPMs exist not only for x86-based platforms, but also for the Raspberry Pi.

In this task, driver support for GPIO-connected TPM for Raspberry Pi single board computers shall be enabled on L4Re. An existing TPM library shall be ported to L4Re, too. The goal is that TPMs can be used by L4Re applications and optionally also from within one or more Linux VMs running on top of L4Re.

Supervisor: Carsten Weinhold