Tracing and profiling low-level kernel functions (e.g. as found in the process scheduler) is a challenging task, though, necessary in both research and production in order to acquire detailed insights and achieve peak performance. Several kernel functions are known to be not traceable because of architectural limitations, whereas tracking other functions causes side effects and skews profiling results.

The growing computational power of modern CPUs allows increasingly complex signal processing applications to be successfully implemented and executed on general-purpose processors and operating systems. In this regard, the application's architecture, its design, and operating system integration directly affect the maximal achievable processing bandwidth. In this paper, we present alternative driver architectures for signal processing applications that differ in the distribution of processing stages between kernel space and user space. Using the processing of ADS-B air traffic radio signals for civil aviation as case study, we evaluate the performance of the design alternatives on a Linux system and quantify their strengths and weaknesses with respect to data overhead, usage of vector units, applicable compiler optimizations, and cache behavior. Based on our results, we determine the best design choice and derive guidelines for the development of efficient signal processing applications.

Reducing the cost of memory accesses, both in terms of performance and energy consumption, is a major challenge in shared-memory architectures. Modern systems have deep and complex memory hierarchies with multiple cache levels and memory controllers, leading to a Non-Uniform Memory Access (NUMA) behavior. In such systems, there are two ways to improve the memory affinity: First, by mapping threads that share data to cores with a shared cache, cache usage and communication performance are optimized. Second, by mapping memory pages to memory controllers that perform the most accesses to them and are not overloaded, the average cost of accesses is reduced. We call these two techniques thread mapping and data mapping, respectively. Thread and data mapping should be performed in an integrated way to achieve a compounding effect that results in higher improvements overall. Previous work in this area requires expensive tracing operations to perform the mapping, or require changes to the hardware or to the parallel application. In this paper, we propose kMAF, a mechanism that performs integrated thread and data mapping in the kernel. kMAF uses the page faults of parallel applications to characterize their memory access behavior and performs the mapping during the execution of the application based on the detected behavior. In an evaluation with a large set of parallel benchmarks executing on three NUMA architectures, kMAF achieved substantial performance and energy efficiency improvements, close to an Oracle-based mechanism and significantly higher than previous proposals.

One of the main challenges for parallel architectures is the increasing complexity of the memory hierarchy, which consists of several levels of private and shared caches, as well as interconnections between separate memories in NUMA machines. To make full use of this hierarchy, it is necessary to improve the locality of memory accesses by reducing accesses to remote caches and memories, and using local ones instead. Two techniques can be used to increase the memory access locality: executing threads and processes that access shared data close to each other in the memory hierarchy (thread affinity), and placing the memory pages they access on the NUMA node they are executing on (data affinity). Most related work in this area focuses on either thread or data affinity, but not both, which limits the improvements. Other mechanisms require expensive operations, such as memory access traces or binary analysis, require changes to hardware or work only on specific parallel APIs.

Solid-state drives (SSD) based on flash memory offer the opportunity to build high-performance storage systems with low energy consumption and high reliability. Crucial concerns of current SSDs are their write performance, especially for small random requests, and the limited lifespan of their flash memory. Both can be mitigated by providing an SSD with information about the stored data. This may include notifications about deal location of storage capacity or the prevalent access type. Knowing the size, latency requirements and type of upcoming requests can help to improve the dataset management (DSM) of an SSD allowing further performance improvement and memory lifetime extension. Often such information has to be passed through intermediate layers (e.g., RAIDs) placed between the information sources (e.g., file system) and the information sinks (i.e., the SSDs). Problems arise because such layers often do not appropriately propagate DSM commands making the intended optimizations unfeasible. In this paper, we propose a file system-independent, layered I/O software architecture that enables the handling of DSM commands throughout all of the layers. Moreover, it allows to address cross-cutting concerns related to the propagation of DSM commands. Its applicability is demonstrated by an exemplary instance based on stacked software RAID layers. The results of an experimental evaluation based on Linux Software RAID clearly show the benefits of the proposed architecture.

Solid-State Drives (SSDs) are about to radically change the way we look at storage systems. Without moving mechanical parts, they have the potential to supplement or even replace hard disks in performance-critical applications in the near future. Storage systems applied in such settings are usually built using RAIDs consisting of a bunch of individual drives for both performance and reliability reasons. Most existing work on SSDs, however, deals with the architecture at system level, the ash translation layer (FTL), and their influence on the overall performance of a single SSD device. Therefore, it is currently largely unclear whether RAIDs of SSDs exhibit different performance and reliability characteristics than those comprising hard disks and to which issues we have to pay special attention to ensure optimal operation in terms of performance and reliability.