Projects

C1: Invasive Run-Time Support System (iRTSS)

Principal Investigators:

Prof. W. Schröder-Preikschat, Dr. D. Lohmann, Prof. J. Henkel, Dr. L. Bauer

Scientific Researchers:

V. Wenzel, A. Pathania, B. Oechslein, J. Schedel, C. Erhardt, G. Drescher, S. Maier, F. Schmaus

Abstract

Subproject C1 investigates operating-system support for invasive applications. It provides methods, principles and abstractions for the application-aware extension, configuration and adaptation of invasive computing systems. These are technically integrated into the invasive Run-time Support System (iRTSS), a highly scalable native operating system in close contact and constant touch with a standard Unix-like host operating system. The project works address special-purpose MPSoC-based as well as general-purpose multi/manycore machines.

The core areas of research in the first funding phase were (1) new design approaches for low-latency operating systems, (2) new methods based on aspect-oriented programming (AOP) for their static and dynamic (re-)configuration and (3) agent-based strategies for the highly scalable management of their resources. Outcome was (1) OctoPOS, a hardware-centric and lock-free parallel operating system of event-based kernel architecture, (2) an aspect-oriented generator for hardware-tailored cross-tile RPCs and (3) a protocol machine for application-centric bargaining of resource allocations.

In the second funding phase, the focus will be on partial virtualisation of selected computing resources - claim virtualisation in terms of invasive computing - to provide for multiprogramming and compensate for a temporary "invasion deficit" at the time those resources are requested. An invasion deficit may be functional or non-functional (e.g. in terms of protection, isolation, or dark silicon) and arises whenever, at the moment of invade, the number and characteristics of the resources available deviates to an intolerable degree from the resources requested. As soon as the cause for that virtualisation has ceased to exist, devirtualisation shall take place. These changes go along with the dynamic reconfiguration of iRTSS, that is, the extension as well as the contraction of the overall system structure and the replacement of individual system components ("open-heart surgery"). The objective is to "charge" applications only with self-induced system overhead in spatial and temporal respect in order to "shield" other applications from a system-induced negative impact on their non-functional properties, such as predictability. Thus, at run time, iRTSS will include only those functions that are indispensable in order to fulfil the requirements of a certain application mix at a given point in time. In the strict sense, iRTSS provides for the "invasion of its own dominion" in a controlled (and not self-destructive) manner. A central role therein is played by the strategic control when to virtualise which (real) resource and reconfigure which entity of iRTSS. The goal here is to accomplish functional transparency by an interface that allows for the specification of abstract resource demands (i.e. non-functional requirements), such as the desired degree of predictability, level of timeliness, or amount of performance for a certain computation period. Behind that interface, iRTSS then translates such semantically enriched requests into a resource allocation and assignment of a (virtual/real) claim that reflects the actual demand against the background of the current system state and, if applicable, in consideration of state changes to be expected in the near future.

Synopsis

Subproject C1 was assumed office to investigate basic system-software support for application-aware static/dynamic configuration and on-demand adaptation of the invasive computing platform - bridging the gap from invasive hardware (project area B) to invasive applications (project area D). Scientific objective was a flexible run-time system coping with massively-parallel, heterogeneous, and dynamic workloads and requirements of the envisioned invasive applications. The challenge was to map (static/dynamic) application properties to iRTSS configuration variants and to efficient instantiation schemes for i-let entities considering cross-cutting, non-functional properties (e.g. economy, timeliness). In this realm, Subproject C1 looked for (1) new design approaches for low-latency in operating systems, (2) novel AOP-inspired methods for their static and dynamic (re-)configuration, and (3) agent-based strategies for the highly scalable management of their resources.

Subproject C1's main focus now is on temporarily virtualisation of hardware resources, in particular to provide multi-programming and multi-user support. Key aspect thereby is to "virtualise on demand", that is, when requested or tolerated by the application and considered advantageous by iRTSS. This will entail a dynamically alterable iRTSS in order to fade-in and fade-out the system functions that are typically needed for virtualisation. Virtualisation enables the invasion of computational performance instead of whole processing elements. Virtualisation also facilitates transparent claim migration and online tuning of claims by the Agent System. Finally, Subproject C1 will also contribute to the "dark silicon" initiative of Subproject B3 as we plan to sensitise resource management to the dynamically changing constraints imposed by high power densities.

Partial virtualisation

As projected in the previous application, iRTSS actually provides uniprogramming in a simultaneous mode, i.e. a run-time executive for parallel processing of single non-sequential programs. The current application pursues the objective to upgrade this executive by system functions for multiprogramming support. These functions include the partial virtualisation of selected computing resources - claim virtualisation in terms of invasive computing - to compensate for temporary shortcomings at the time those resources are requested. Processing element (PE), energy unit and (program) address-space range denote the types of resources that are considered most relevant in the first place. A further goal is to countermand all measures that have been "mounted" previously in the course of enabling claim virtualisation for want of resources when the cause for it has ceased to exist (devirtualisation). Purpose of these measures is less to allow for better system utilisation but rather to dynamically clear out hardware (on-demand, anticipatory) for exclusive use by applications with strict predictability requirements.

Dynamic reconfiguration

Claim virtualisation is considered as a means to an end in the provision of a versatile run-time executive that changes its exoteric as well as introversive functional and non-functional appearance depending on the (internal and external) processes it has to control. This change goes along with the dynamic reconfiguration of iRTSS, the extension as well as the contraction of the overall system structure, and the replacement of individual system components ("open-heart surgery"). The objective of this is to "charge" applications only with self-induced system overhead in spatial and temporal respect. Thus, at run time, iRTSS will offer only those functions - and include only those routines - that are indispensable in order to fulfil the requirements of a certain application mix at a given point in time. In the strict sense, iRTSS provides for the "invasion of its own dominion" in a controlled (and not self-destructive) manner. Ambition is to provide means that allow for invasion, infection and retreat at the level of abstraction of virtual machines and no longer real machines.

Strategic control

A key role is taken by the decision making on when to virtualise which (real) resource and when to reconfigure which entity of iRTSS. Decision making is carried out by the Agent System, on the one hand on demand, once a request for invasion has been put down by an application program, and on the other hand in an anticipatory manner, whenever iRTSS performs system-state changes that may redound to the current application's advantage. For the acceptance of invasive computing as just refined - not only when regarding virtual, but already in case of real machines - functional transparency is essential: iRTSS must hide its (structural) complexity from higher levels, but not its features. The goal is to accomplish this by an interface that allows for the specification of abstract resource demands (i.e. quality requirements), such as the desired degree of predictability, e.g. with respect to timeliness, or the amount of performance for a certain computation period. Behind that interface, iRTSS translates such semantically enriched requests into a resource allocation and assignment of a (virtual/real) claim that reflects the actual demand against the background of the current system state and, if applicable, in consideration of state changes to be expected in the near future. The system state is influenced from the hardware level (by interactions with the dark-silicon management (subproject B3) and from changing resource demands of applications.

Scientific objective

The research question of the current application emanates from (a) the achievements of the first funding phase and (b) the existing knowledge on partial virtualisation to compensate for temporary resource shortness, on dynamic reconfiguration of kernel-level system software to adapt to resource-virtualisation measures, and on strategic control based on semantically enriched resource-allocation requests to provide for functional transparency. Our basic assumption is that the paradigm of invasive computing particularly applied to system programming is feasible and promotes system-level operating sequences needed to comply with application level predictability requirements. Based on this, the special implication a selective dynamic operating-system structure has on the (predicted) performance of invasive-parallel processes is scrutinised. Likewise, we will try to get to the bottom of the general implications this approach has for the operation of commodity manycore multiprocessor systems.

Detailed Description: OctoPOS

The system software OctoPOS acts as a broker between the X10 runtime system with its applications and the underlying hardware.

Interaction with the X10 runtime system

The OctoPOS provides an interface for mapping the different activities inside an X10 programm onto the different flavours of invasive hardware. Depending on the actual hardware configuration, this process can be partially supported dedicated hardware, for instance by the Dynamic Many-Core i-let Controller (CiC). Moreover the OctoPOS implements facilities for intra-tile, cross-tile and cross-application communication using shared memory, where available, or the invasive NoC (iNoC).

Interaction with the underlying hardware

Among the supported hardware platforms are SPARC Leon, iCore and Intel x86. In addition, it is possible to run OctoPOS as a user process within a Linux system, enabling developers to test applications with the entire invasive software stack.

A comprehensive summary of the major achievements of the first funding phase can be found by accessing Project C1 first phase website.

Publications