Energy e ciency 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 a ecting 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 a ord huge costs due to the power
consumption and the cooling of the infrastructure. Furthermore, the dark silicon
phenomenon a ecting modern processors is becoming prominent[
On the application side, we can gain e ciency 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.
C C++ OpenCL
Recipes RPC Channel FIFOs/Binder
DBus Application Proxy Application Manager Power Manager CPUfreq Synchronization
Protocol Synchronization
Policy Synchronization Manager AEM API Plain API AS-RTM API
Scheduler Policy Resource Accounter Scheduler Manager Resource Manager Platform Proxy
Platform Drivers Control Groups
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 di erent 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-speci c 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 [
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 de ning 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 con gure 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 BarbequeRTRM. 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 con gure itself accordingly, before starting (or continuing) the execution, as sketched here below. RTLIB ExitCode t BlackscholesEXC : : onConfigure ( i n t 8 t awm id ) f // Get t h e number o f CPU c o r e s a s s i g n e d
GetAssignedResources ( RTLIB ResourceType : : PROC NR, n r c p u ) ; g
// C o n f i g u r e . . .
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 e ective approach is to exploit the SetCPSGoal function to specify the performance goal and the noti cation rate, as shown in the following example of onMonitor implementation: RTLIB ExitCode t BlackscholesEXC : : onMonitor ( ) f // 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 ) ; // . . . g
In the example, the application sets a performance goal of 2.5 CPS, and a noti cation rate of 10 cycles. The library keeps track of the application performance, computing the average CPS value over a (con gurable) number of last execution cycles. Whenever the performance gap overcomes a given (congurable) threshold, such a gap value is sent to the resource manager. As a consequence, the amount of assigned resources can be adjusted accordingly. The noti cation rate is then exploited to bound the application recon guration rate, and hence the related overhead. In other words, the application asks the resource manager to send back a recon guration request after not less than 10 execution cycles or more. 3
In this section we show results of the resource-aware adaptive execution of
blackscholes from the PARSEC benchmark suite [
LTohaedBarbequeRTTeRmMp:ePraotwuerer data traceFprleoqtuency 90 80 40 30
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.