Energy efficiency and thermal management have become major concerns in both embedded and HPC systems. The progress of silicon technology and the subsequent growth of the dark silicon phenomena are negatively affecting the reliability of computing systems. As a result, in the next future we expect run-time variability to increase in terms of both performance and computing resources availability. To address these issues, systems and applications must be able to adapt to such scenarios. This work provides a brief overview of the Barbeque Run-Time Resource Manager (BarbequeRTRM ) and the application execution model that it exploits, in order to deal with run-time performance and available resources variability.
The need of resource-aware and adaptive applications is driven by several issues and requirements that are typical of modern computing systems. For instance, embedded mobile devices must deal with the limited energy budget provided by the battery, while HPC centers must afford huge costs due to the power consumption and the cooling of the infrastructure. Furthermore, the dark silicon phenomenon affecting modern processors is becoming prominent [1], since it is increasing the amount of silicon area that must be turned off, to guarantee the power envelope of the processor. For all these reasons, a continuous and full usage of the whole set of system computing resources is often impossible to achieve.
On the application side, we can gain efficiency by implementing suitable adaptive behaviors like enabling/disabling the execution of a task, or scaling the accuracy of the output depending on the availability of computing resources. A run-time resource management framework can implement such approach by constraining the resource allocation according to system level requirements or runtime conditions, and providing to the applications suitable interfaces to check and negotiate the resource assignment.
Fig. 1. The BarbequeRTRM Architecture. On top the programming languages supported by the application Run-Timr Library (RTLib). In red the resource manager core, on top of the support provided by the Linux OS to control the system resources.
The BarbequeRTRM is a modular and portable run-time resource manager targeting both embedded and High-Performance Computing (HPC) systems. From the hardware resources perspective, the framework can manage homogeneous and heterogeneous multi-core processors, as well as heterogeneous systems including devices characterized by completely different ISA (e.g., CPU and GPU).
The modularity of the BarbequeRTRM comes from a software architecture in which we can distinguish between core components and plugin modules. Typically, the latter are platform-specific extensions and selectable resource management policies.
The portability instead, is guaranteed by the exploitation of some underlying Linux operating system frameworks, like cpufreq and cgroups, that allows the BarbequeRTRM to enforce the resource allocation decisions [2].
The resource manager exposes its services to the applications through a run-time library (RTLib). The library accomplishes a two-fold objective: 1) to provide a Fig. 2. Abstract Execution Model communication channel between the resource manager and the applications; 2) to expose an execution model to support the implementation of the resourceaware adaptive execution of the applications [3].
In Figure 2 we show the Abstract Execution Model (AEM), that the run-time manageable applications must implemented accordingly. This execution model is put in place by defining and implementing a suitable C++ class, derived from the BbqueEXC class provided by the RTLib.
At run-time, the BbqueEXC member functions are called by a control thread, which is responsible of synchronizing the application execution with the decisional process of the resource manager. The rationale behind each member function implementation is the following: onSetup(): setting up the application (initialize variables and structures, starting threads, . . . ). onConfigure(): check the amount of assigned resources and configure the application accordingly. onRun(): single cycle of computation (e.g., computing a single frame during a video encoding). onMonitor(): performance and QoS monitoring. onRelease(): cleanup and termination code.
Therefore, once the application ends the initialization step (onSetup), the control thread waits for the resource allocation decision coming from the Barbe-queRTRM. As soon as it has been received, the onConfigure function is called. In this function, the application can then check the amount of assigned resources, and configure itself accordingly, before starting (or continuing) the execution, as sketched here below. The functions onRun and onMonitor are then sequentially called and executed in a loop, until the entire computation is over.
The RTLib estimates the current performance of the application, in terms of cycles-per-second (CPS), such that the application could check the gap between the required performance level and the one currently achieved. After that, the application can notify the resource manager about this gap.
Considering also that the performance goal can vary depending on input data and external events, a effective approach is to exploit the SetCPSGoal function to specify the performance goal and the notification rate, as shown in the following example of onMonitor implementation: RTLIB ExitCode t BlackscholesEXC : : onMonitor ( ) { // S p e c i f i c e v e n t c o n d i t i o n t r i g g e r i n g t h e // change o f performance r e q u i r e m e n t s i f ( . . . ) SetCPSGoal ( 2 . 5 , 1 0 ) ; // . . . }
In the example, the application sets a performance goal of 2.5 CPS, and a notification rate of 10 cycles. The library keeps track of the application performance, computing the average CPS value over a (configurable) number of last execution cycles. Whenever the performance gap overcomes a given (configurable) threshold, such a gap value is sent to the resource manager. As a consequence, the amount of assigned resources can be adjusted accordingly. The notification rate is then exploited to bound the application reconfiguration rate, and hence the related overhead. In other words, the application asks the resource manager to send back a reconfiguration request after not less than 10 execution cycles or more.
In this section we show results of the resource-aware adaptive execution of blackscholes from the PARSEC benchmark suite [4] on a embedded development board that features an ARM Cortex A9 dual-core CPU. The benchmark has been properly modified to fit the Abstract Execution Model. The frequency of the CPU has been set to its maximum value, which is 920 MHz. The full CPU usage, which is shown in Figure 3a, causes the chip temperature to raise over 100 • C, thus triggering the thermal throttling response of the operating system.
A continuous frequency scaling is operated in order to cool down the CPU, with performance variability as a further consequence.
In Figure 3b, the application sets a performance goal of CPS=1. The resource manager takes into account such information shrinking the amount of CPU time assigned. The implicit result is a lower but more stable performance level, along with a reduced thermal stress.