Defining Scalable OS Requirements for Exascale and Beyond
Robert W. Wisniewski, Chief Software Architect for Extreme Scale Computing, Intel
Over the past couple of decades two primary trends have driven system software for supercomputers to become significantly more complex. First, hardware has become more complex. Massive inter-node parallelism (100,000+ nodes), increasingly large intra-node parallelism (100+ hardware threads), wider vector units, accelerators, coprocessors, etc., have required that system software play a larger role in delivering the performance available from this new hardware. Second, applications have changed. Historically, extreme-scale high-performance computing (HPC) applications were stand-alone executables that were bulk synchronous, spatially and statically partitioned, and required minimal system services.
As the community moves towards exascale, applications are being integrated into workflows, require big data and analytics, are incorporating asynchronous capabilities, and demand an increasingly rich set of libraries, runtimes, and system services. As part of providing comprehensive system services, the compute node operating system is being integrated into the control system, which is sometimes referred to as the global operating system. While providing a complete set of system services is important, this article focuses on the challenges and needs of the Operating System (OS) on the compute node. Figure 1 shows the “left to right” model typical in HPC systems, the control system, and the node-local OS. We describe how these trends are changing the requirements and hence design of the HPC compute node OS, and describe promising directions for how these challenges will be met for exascale computing.
Background:
In addition to the above challenges, the compute node OS, hereafter just OS, must address an additional challenge. There has been a debate in the software community about whether a revolutionary or an evolutionary approach is needed to achieve exascale. We contend both are critical, and that the real challenge for system software to get to exascale and beyond is figuring out how to incorporate and support existing computation paradigms in an evolutionary manner while simultaneously supporting new revolutionary paradigms. The OS must provide this capability as well.
Historically, two designs have been used for operating systems. One is to start with a Full-Weight Kernel (FWK), typically Linux[i], and remove features so that it will scale up across more cores and out across a large cluster. Another approach is to start with a new, Light-Weight Kernel (LWK) and add functionality to provide a familiar API, typically Linux.
Requirements:
Linux, or more specifically the Linux API, including glibc and the Linux environment (/proc and /sys) is important for supporting the evolutionary aspect and for addressing the described complexity needs. There is a set of classical needs that are interrelated and must be met, including low noise, high performance, scalability for capability computing, and allowing user-space access to performance critical hardware, e.g., the network. There is a set of emerging needs that include the ability to handle asynchrony, manage power locally and globally, handle re- liability, provide for over commit of software threads, and interact effectively with runtimes. The classical needs allow applications to achieve high performance while the emerging needs provide for higher productivity and support of new programming and execution models.
A key requirement for an exascale OS kernel is nimbleness, the ability to be modified quickly and efficiently to support new hardware and to provide targeted capabilities for the HPC libraries, runtimes, and applications. This is opposite of the requirement for a general purpose OS, whose success is based on broad-based use with known interfaces. High-end HPC systems, those that will first achieve exascale and beyond, push the edge of technology out of necessity and introduce new hardware capabilities that need to be utilized effectively by high-end HPC software. As an example, a decade ago, large pages were integrated into CNK, Blue Gene’s LWK in about six months while large page support in major distributions of Linux took significantly longer and remains an on-going effort. The reason is CNK’s limited application domain allowed many simplifying assumptions. New hardware technology will be required to achieve exascale computing, and applications will need to aggressively exploit the new technology. Thus, what is needed, is an approach that while preserving the capability to support the existing interfaces (evolutionary) provides targeted and effective use of the new hardware (revolutionary) in a rapid and targeted manner (nimbleness).
Approaches:
The historical approaches of adding features to an LWK or trimming an FWK have additional weaknesses when trying to simultaneously support revolutionary and evolutionary models while trying to achieve high performance in an increasingly complex and rich environment. LWKs have been shown to exhibit low noise that allows high scalability. They also have been able to target the specific needs of HPC applications allowing higher performance. As the community moves to exascale, the need to leverage specific hardware and tailor the OS service to application needs, will become more important.
Three classes of approaches are emerging to overcome these weaknesses.
- The first is to continue to use Linux as the base and containers to limit the interference between multiple applications thereby allowing the different applications (often a classical HPC and an emerging one, e.g., analytics or visualization) to share a node’s resources while trying to minimize the effect on the classical HPC application. Containers provide a virtual environment in Linux that provide the appearance of isolated OS instances. In the Linux community there is considerable excitement and work involving containers and HPC may be able to leverage this broader base of activity. The challenge with the container approach is that Linux remains underneath and any fundamental challenge with Linux itself remains.
- The second approach is virtualization. A virtualized platform on which either an LWK or a Linux kernel can run provides high performance or the features of a more general purpose OS. It is important to ensure that the cost of virtualization, especially for the LWK, is kept to a bare minimum. This approach in isolation presents problems for simultaneous use of the LWK and FWK by the application, but could be combined with the approach below.
- The third approach is to run multiple kernels simultaneously on a node. This has been an area of intense effort in the last several years and many efforts including McKernel, FusedOS, Nix, Tesselation, Popcorn Linux, and mOS are exploring this path. We will describe mOS as an example. The vision is to run an LWK on the majority of the cores to achieve high performance and scalability, while running Linux on one or a small number of cores to provide Linux compatibility. From the application’s perspective it achieves the performance of an LWK but appears to be Linux.
Figure 2 depicts the fully generalized mOS architecture for the research direction we are exploring in the multiple kernels space. While the figure depicts the full generality, we expect most instantiations to run a single application on a single LWK. A standard HPC Linux runs on a given core(s); an LWK(s )runs on the rest of the cores. On any given LWK, one or more applications may run. As mentioned, the expected scenario is to run Linux on one core, and one application on one LWK on the rest of the cores. When the application makes a system call, it is routed to the OS Node (via arrow 1b) if it is a file I/O operation, or to the LWK on the core that made the call (via arrow 1a). The LWK will handle performance critical calls. If it is a call that is not implemented by the LWK, then the LWK will transfer the call to Linux (via arrow 2) to be serviced. Linux will service the call and return to the LWK, which in turn returns back to user space on the original core. With this methodology, the application achieves the high performance and scalability offered by an LWK while providing the Linux environment. We have worked out an architecture for mOS and have early prototype code that is allowing us to confirm several of the architecture decisions we made.
Conclusion:
System software for exascale systems is of necessity becoming more complex. The compute node OS, and how it supports the compute node runtimes and interacts with the global control system, will play a critical role in allowing us to achieve exascale and beyond. To be evolutionary and revolutionary simultaneously, the OS must meet the classical and emerging HPC requirements. A promising direction that several groups are exploring to address these needs is running multiple operating system kernels on a node simultaneously. While significant challenges remain and innovative work is still needed on the OS front there is confidence in being able to get the community well beyond exascale computing.
Author Bio:
Dr. Robert W. Wisniewski is an ACM Distinguished Scientist and the Chief Software Architect for Extreme Scale Computing and a Senior Principal Engineer at Intel Corporation. He has published over 60 papers in the area of high performance computing, computer systems, and system performance, and has filed over 50 patents. Before coming to Intel, he was the chief software architect for Blue Gene Research and manager of the Blue Gene and Exascale Research Software Team at the IBM T.J. Watson Research Facility, where he was an IBM Master Inventor and lead the software effort on Blue Gene/Q, which was the fastest machine in the world on the June 2012 Top 500 list, and occupied 4 of the top 10 positions. Prior to working on Blue Gene, he worked on the K42 Scalable Operating System project targeted at scalable next generation servers and the DARPA HPCS project on Continuous Program Optimization that utilizes integrated performance data to automatically improve application and system performance. Before joining IBM Research, and after receiving a Ph.D. in Computer Science from the University of Rochester, Robert worked at Silicon Graphics on high-end parallel OS development, parallel real-time systems, and real-time performance monitoring.
[i] Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.