Task-RM: A Resource Manager for Energy Reduction in Task-Parallel Applications under Quality of Service Constraints

This article targets precedence-constrained task-parallel applications that are increasingly gaining popularity among modern task-parallel programming models, e.g., OpenMP [15, 17]. Such applications are typically represented by a DAG, where nodes represent tasks and edges represent dependencies between tasks. In this article, the DAG constitutes a tuple G = (T, E, U), where T is the set of t tasks, E is the set of e edges, and U is the set of t task UBETs. Moreover, the hardware platform is represented by a tuple H = (P, C, V-F), where P is a set of p processors, C is a set of c core types, and V-F is a set of v legal voltage-frequency pairs. An example of a DAG is shown in Figure 1. Here, the task identities are denoted as Ti, and the UBET of a task is represented by the number at the bottom of each circle.

One can simulate the execution assuming a specific processor allocation and using the tasks’ UBETs, the DAG, and a scheduling algorithm to compute an offline schedule. This simulation establishes the worst-case schedule length (WCSL). However, the actual execution behavior may differ, and the RM needs to identify these variations and apply energy-saving strategies. Specification of a deadline aids the RM in applying energy-saving optimizations while meeting the deadline. This is accomplished by assigning performance requirements in terms of soft deadlines or so-called latest finish times (LFT) to individual tasks using the worst-case schedule (WCS) simulation.

A worst-case off-line schedule of a DAG is presented in Figure 1 using the earliest finish time (EFT) scheduling as shown in Figure 2 for a processor count of four. This is the worst-case execution under the assumed scheduling method and processor count. The schedule takes 14 time-units (TU) to complete, i.e., the WCSL is 14. The QoS specification must be equal to or greater than the WCSL to be feasible in all execution scenarios. Moreover, to ensure the application is completed before the deadline, all tasks must finish before the scheduled finish times in this worst-case schedule. Thus, soft deadlines, or task LFTs, are initially set equal to the finish times of the tasks as per a worst-case schedule. Such an LFT assignment is shown in Table 1, where, for example, the LFTs of T1 and T2 are set to 2 and 5, respectively, using their finish times in the WCS simulation. There also exists some more optimization that will be discussed in the next section.

There are three main opportunities that, once identified, can be used for applying energy-saving measures. The first opportunity occurs when a task completes earlier than its UBET. The successor tasks can start early in such a case and can be slowed down to save energy. Such a scenario is depicted in Figure 3(a), where T1 completes at 1 TU; however, its scheduled finish time based on UBET is 2 TU. If we assign the LFTs to the task’s successors, the RM can allocate just enough resources to the tasks to finish before their respective LFTs, thus saving energy. This applies to all the tasks in the DAG. For example, using the off-line schedule in Figure 2, we can assign the LFT for each task as shown in Table 1. In the scenario under discussion, the early finish of T1 allows its successors T4, T3, T6, and T5 to start early, but they only need to finish before their respective LFTs of 3, 4, 4, and 4 TU, respectively. The RM can use the slack produced by a task’s successor to allocate just enough resources so that the tasks finish before their respective deadlines, thus saving energy.

The second opportunity is to exploit the imbalance between the predecessors of the tasks as illustrated in Figure 3(b). According to the off-line schedule in Figure 2, T3 finishes before its sibling T2. These two tasks, along with T4, are the predecessor of T8, and T8 can only start after the completion of its three predecessors. Thus, relaxing the LFT for T3, equal to the LFT of T2, allows the RM to save more energy. The same opportunity can be exploited in the case of T5 and T11, and their LFTs can also be relaxed to the LFTs of T7 and T12, respectively. The result of this optimization is shown in Table 2.

The third opportunity arises when, during execution, additional processors become available. This scenario allows tasks to start earlier than when they were originally scheduled to start. Hence, it allows more tasks to execute in parallel. Figure 3(c) depicts such a scenario, where six processors are available instead of the original assumption of four. T2 and T7, which were originally scheduled to start after T4 and T6, respectively, can now execute in parallel. This scenario does not only need less resources to T2 and T7 but also allows the allocation of less resources to T4 and T6 as they only need to be completed as late as their siblings. In traditional systems, such a change in computing resources typically requires a re-evaluation of the schedule and LFTs. However, it is not feasible in an on-line scheme because it will incur large overheads. Instead, we propose to construct an LFT table with a set of processor counts off-line and provide it to the RM. An example of such an LFT table is shown in Table 3, where the LFT for a processor count of 4, 5, and 6 is shown. Note that, in the case of a given DAG (i.e., Figure 1), there is no advantage of increasing the processor count beyond six because the maximum parallelism available in the example DAG is six.

In summary, identification and exploitation of the aforementioned opportunities is critical for energy reduction and the next section discusses the proposed resource management scheme in detail.

Our resource management proposal to reduce energy consumption consists of two key components: (1) Off-line analysis and (2) Run-time resource management. Our scheme requires the user to specify QoS in terms of a program deadline, task UBETs, a scheduling method, the baseline processor configuration and additional processor count. Please note that we refer to the scheduling method as the task priority criterion to pick the tasks to be executed next when the number of ready tasks is higher than the available processor count.

The off-line analysis uses this information to compute the LFT table that provides soft deadlines for the tasks. Adherence to these soft deadlines ensures that the program finishes close to its soft deadline. At run-time, the RM uses task LFTs and performance predictions to allocate just-enough resources leading to higher energy efficiency. Figure 4 depicts the system’s block diagram, where the system components highlighted in blue are contributions of this article. The off-line analyzer comprises an off-line scheduler and a schedule analyzer. The RM in the run-time system is invoked whenever a task completes or processors become available and consists of an on-line scheduler and a resource manager denoted Task-RM.

The on-line scheduler finds the tasks that are supposed to be executed next and the Task-RM estimates an appropriate resource allocation in terms of processor-mapping and frequency using off-line analysis and a prediction of the task’s execution time and energy consumption. Consequently, tasks execute on the estimated configuration (i.e., processor-mapping and frequency) and measured execution statistics (e.g., instruction count) are fed back to the Task-RM, which in turn will be used for prediction in the next scheduling epoch. The whole process repeats itself until the execution of the application is complete. Please note that both the off-line and on-line schedulers are not part of our contributions and that our framework is agnostic to the choice of scheduler.

The off-line analyzer computes the content of the LFT table to be used by the run-time resource manager. This allows our scheme to avoid run-time overhead. The LFT table provides the latest finish times, that serve as soft deadlines, for all tasks. Finishing each task as close as possible to its respective deadline ensures that the program deadline is met and saves energy. The LFT table is computed for a range of processor counts that allow our scheme to work for any number of processors within a predefined range without re-computing the LFT table at run-time. Consequently, the RM can read LFTs of these tasks for a specific processor count at run-time.

The procedure for off-line analysis is depicted in Algorithm 1 in function OffLine_Analysis. To compute the content of the LFT table requires task UBETs, the baseline configuration, and the QoS specification. It comprises four steps. First, an off-line schedule is simulated using task UBETs and the DAG for the baseline processor count, as represented by Compute_Base_Schedule on line 13. This is a trivial step that is well established in state-of-the-art and will not be covered in detail. The baseline schedule (\(\text{Schedule}_\text{base}\)), the baseline LFT, the task ready-time (RT) and the task start-time (ST) are computed in this step. An example of such a schedule is shown in Table 4, where each entry in the table represents a scheduling instant. At each instant, a new task is assigned to any of the processors, as shown in columns P1, P2, P3, P4. The column labeled “Time” represents the scheduling time. If no task is allocated to a certain processor at a certain instant, the corresponding entry is marked by “-1”. Moreover, the ready, start, and completion times of the task are also recorded as shown in Table 6, where ST and RT refer to start-time and ready-time, respectively. Ready-time is when a task becomes ready after all its predecessor tasks have completed execution, and start-time is when a task begins execution. The completion time of each task provides the base LFT table. The completion time of the last task in this schedule defines the overall completion time or makespan. The ST and RT tables will be used in the analysis of schedules.

The next step is to find the imbalance between sibling tasks and relax their LFTs. The Analyze_Schedule function carries out this operation (line 14). The function definition for Analyze_Schedule is shown on line 26. The algorithm loops over every entry in the schedule (line 28) and checks if any processor is available, i.e., is marked by -1. In case a processor is not allocated a task (lines 29–30), the task previously allocated to that processor (\(\text{Previous}\_\text{Task}\)) is retrieved (lines 31–32) and checked (line 33). If any of the tasks currently executing is not a successor of the \(\text{Previous}\_\text{Task}\) (line 33), then the \(\text{Previous}\_\text{Task}\) is again allocated an execution slot on the same processor in the current scheduling instant (lines 34–35). The result of applying this algorithm to the example schedule in Table 4 is shown in Table 5, where the changes are highlighted in blue. Moreover, the LFT of this task is adjusted accordingly. The Analyze_Schedule procedure comprises of two nested “for loops”; the first loop iterates over the number of entries of input schedule and the second loop traverses the number of allocated processors. The number of entries depends on the number of tasks, the DAG, and the available processors. The upper bound case occurs if the processor count is set to one, where the number of entries in the schedule is equal to the task count. Thus, the complexity of this function is O(t*p)

The next step involves finding the task LFTs for the range between the base processor count and the maximum processor count as depicted by the For loop on line 16. Every iteration of this loop computes a schedule (line 17) for the processor count between \({{}}{P}_\text{base}+1\) and \({{}}{P}_\text{Max}\). The schedule is also analyzed for task imbalance using the already discussed Analyze_Schedule function (line 18), and the LFT is compiled and recorded into the LFT table (line 19).

The user-provided program deadline can be equal to or greater than the makespan. The task LFTs must be adjusted according to the user-defined deadline. This is accomplished by merely scaling the LFTs (lines 21–23). First, the deadline specified by the user is divided by the makespan to get an extension factor. Completion times of all tasks are multiplied with the extension factor to compute the final LFT table.

The algorithm for Compute_Schedule function is depicted in Algorithm 2. This function primarily simulates the execution using task UBETs but with some conditions. The function Allocate_Task kicks off the execution by assigning task T0 to processor P0 (line 15). Then the “while loop” (line 16) executes until all the tasks are executed. In each iteration of the loop, the availability of free processors is first evaluated, i.e., Processor_Free (line 14). If processors are free for allocation, the allocation procedure is initiated (lines 15–24); otherwise, the time is incremented (line 26). The allocation procedure consists of several steps. First the tasks are checked for completion by Check_Completed_Tasks function (line 15). This function updates the schedule and returns the completed task numbers and the tasks’ completion times. The completion times are recorded in the LFT array (line 16). Next, the available free processors are checked (line 17), after which the tasks are checked for their readiness because the successors of the newly completed tasks are also ready for execution now (line 18).

The next step is to allocate every free processor with a task (lines 19–24), where first, the highest priority task is evaluated, i.e., Get_High_Priority_Task() and then this task is allocated to a free processor, provided that one of the two conditions is met. As for the first condition, the elapsed time must be greater than the task’s start time as recorded in the ST-table. The second condition evaluates whether the task started as soon as it became ready, by comparing the “start time” and “ready time” of the task. In case both the times are equal, the “start time (ST)” of this task must be kept the same. On the contrary, if the task started later after being ready, then it can start execution early. In short, this allows the early start of only those tasks which executed later due to lack of available processors (refer to Table 6). Moreover, the task LFTs are also adjusted to harness additional energy savings. If the finish time (i.e., Start Time \(+\) UBET) based on the new start time is less than the “base LFT” (line 23), then the LFT of the task is kept the same (line 24). Alternatively, if the task’s finish time (i.e., Start Time \(+\) UBET) is greater than the “base LFT,” then the LFT of the task is changed to “Start Time \(+\) UBET” (line 26). The task is then allocated to the processor for this time duration, i.e., “ST till LFT” calculated above, and the control returns to the start of the loop to schedule the next task. This process is repeated until all tasks have completed execution. The output of this process is the final LFT table, which, if adhered to, would lead to energy minimization and satisfaction of QoS constraints. The time complexity of the Compute_Schedule procedure is O(t), where t is task count in the program.

The objective of the run-time resource management is to allocate enough resources to the tasks so that the program finishes as close to the deadline, specified by QoS, as possible. This is accomplished by allocating appropriate resources to each task so that it finishes before its LFT. Note that the run-time system will only use the final LFT-table produced at the end of the off-line analysis, and no further analysis is done. The Task-RM will allocate resources so as the tasks finish before their soft deadlines, as depicted in the LFT table. Every time a task completes or processors become available, the run-time system module is invoked as shown in Figure 4.

A block diagram of run-time system detailing the internals of Task-RM is show in Figure 5. Here, first the on-line scheduler finds the high-priority tasks next in line for execution, and the Task-RM finds an appropriate resource allocation for the tasks. The Task-RM consist of two components; first, a resource manager controller as discussed in Section 3.3.1, and second, an architectural prediction mechanism that is used to predict the task execution behavior as presented in Section 3.3.3. The RM controller invokes the predictor for each task and receives the prediction that is used for resource allocation.

This article assumes a hardware platform inspired from the ARM big.LITTLE [25] architecture and is shown in Figure 7. Eight big and eight LITTLE cores are arranged in four homogeneous clusters, where two clusters consist of big cores and two consist of LITTLE cores. Cores within a cluster share the LLC and the cache-coherent interconnects (CCI) connect the neighboring LLCs to allow fast data transfer between the clusters. The big and LITTLE cores are assumed to be ARM CORTEX A15 and A7, respectively, same as in the Exonys 5422 [10] SoC available on an ODROID-XU3 board. The A15 is a performance-oriented, out-of-order core while the A7 is an energy-efficient, in-order core. Each core has a 32-KB private L1 cache. The big cluster has a 2-MB shared LLC while the LITTLE cluster has a 512-KB shared LLC. In short, one can assume this hardware as an extension of ARM big.LITTLE that offers a higher level of parallelism. All the cores are assumed to be able to operate on voltage-frequency levels that are the same as available in the ODROID-XU3 board, as shown in Table 7.

The central theme of our simulation methodology is to closely emulate the application’s execution behavior on real hardware, i.e., odroid XU3. Thus, as a first step, we execute the applications on real hardware to record the execution data trace for all possible distinct energy footprint scenarios. In our case, these scenarios or so-called configurations refer to unique combinations of core types and voltage-frequency (V-F) pairs. In short, each DAG is executed on the odroid board on all configurations, and an execution data trace at a granularity of a task is recorded.

An example scenario depicting this is shown in Figure 8. The measured values include the instruction count, cycles, LLC misses, and energy consumption. The second step is to simulate a dynamic execution using above-mentioned execution data trace employing the Task-RM scheme.

Execution data for each task is picked from one of the execution traces based on Task-RM decisions, as shown in Figure 8. For example, the first task T1 executes at the fastest configuration, i.e., big core - 2 GHz, and data for T1’s execution at the corresponding configuration is selected from the execution data trace.

Then, overheads associated with V-F switching, core migration, and Task-RM are added, and the resultant data is both recorded in a dynamic execution log and fed back to Task-RM for prediction purposes, as shown earlier in Figure 5. Finally, Task-RM uses it to predict the resource allocation for the next-in-line task, i.e., T2. As shown in Figure 8, Task-RM predicts to execute T2 at 1.8 GHz-big core; hence, the data for T2 at 1.8 GHz - big core is selected from the execution data trace. This data is recorded in the dynamic execution log and fed back to Task-RM . This process repeats until the completion of the application. For each task, the data for a predicted configuration by Task-RM is read from the execution data trace and recorded in the dynamic execution log. At the end of the application, the dynamic execution log is aggregated to compute the result for the complete execution.

The simulation framework employed in this article is outlined in Figure 9. The first step is the instrumentation of the application source code for two purposes. The first purpose is to extract the task dependency information to generate a DAG, while the second is to record the execution data trace. The DAG is essential for the scheduler to execute the application with correct functional behavior. The source code is transformed to print out task dependency information while executing on a faster non-native machine. The DAG generator processes the information to generate a DAG for the application. The DAG is both used for off-line analysis and run-time resource management. Both these steps are highlighted in green in the figure. Please note that this is an optional step, because if the user provides the DAG, then this step becomes redundant.

The second transformation of the source code is done to measure the task execution statistics by inserting routines to read the hardware performance counters before and after task execution. The modified applications are executed on the ODROID-XU3 board containing the Exonys 5422 [10] SoC on all the configurations. In context of the chosen hardware, there are thirteen V-F settings for the big-cores and ten for the LITTLE-cores, which amounts to 23 configurations in total. The execution statistics are measured for each task while executing applications using a single thread.

This execution data trace is then used for off-line analysis and run-time simulation. In context of our proposal, the user provides the UBETs and the baseline configuration, both of which are then used to carry out off-line analysis and establish the LFT table. Off-line analysis, as discussed earlier, computes the LFT for a range of processor counts from the baseline configuration to the maximum processor count as specified by the user.

The run-time simulation uses the execution data trace, DAG, and LFT to compute the modified schedule. The resource manager block is the same as explained in Section 3. Once the Task-RM determines the task mapping and V-F assignment, the “Task Execution Simulation” block records the task’s execution from the real execution data trace in the schedule. Concerning the resource sharing (i.e., shared LLC), the execution statistics might change as sharing could induce destructive/ constructive interference that will result in different LLC misses, task execution time and energy. The exact effect of this interference is difficult to establish considering the scope of this paper. Instead, we argue that this interference will be the same for all the schemes, i.e., Race-to-Idle, Oracle, and Task-RM ; thus, it is fair to ignore its effect. In short, this simplistic model allows us to carry out the experiments quickly.

The process of task scheduling and resource allocation is continued until all the tasks are completed. Once the application is complete, the schedule is analyzed by the Execution Statistics Generator (see Figure 9) to compute the evaluation statistics.

The run-time resource manager, i.e., Task-RM, is implemented in C++ and executed on real hardware to establish its execution time and energy overheads. These values are recorded as overheads whenever the Task-RM is invoked in the simulation framework.

Other overheads include DVFS switching (assumed to be 10 microseconds [26]) and performance-counter reading overhead (measured to be 500 cycles per counter). Since the off-line analysis is done once for the lifetime of the application, its overheads are not considered.

This article employs applications from the BSC Application Repository (BAR) [9] for evaluation. These applications are written in OmpSs, where successive iterations of algorithms are parallelized using precedence constrained tasks, and thus are a good fit for our proposed scheme. However, we have modified these benchmarks to comply with the dependence model of OpenMP 4.0 for evaluation. This includes syntax transformation of the task specifications and adding data dependency clauses. Moreover, OmpSs implementation lacks the specification of parallel regions as parallelization is done by nanos at run-time. In case of OpenMP, one needs to specify the parallel regions that encapsulate the tasks and the said modification is also carried out in the code. The resultant code is published on-line [5] and available for future use.

The applications used in the evaluation are listed in the Table 8 and include four different kernels with various inputs. In total, there are twelve unique workloads that are used for evaluation. To demonstrate the variety of the workloads considered, we also provide a number of workload characteristics, i.e., the number of tasks, the number of task types, and the total execution times. Here, it can be seen that workloads cover a wide spectrum in terms of the above-mentioned characteristics to evaluate our proposed scheme.

Three schemes are evaluated in this article, the details of which are explained below:

Our proposed scheme requires certain parameters/inputs from the user which must be assumed in order to carry out the evaluation. In the following, we provide details of these user specifications used for evaluation.

In this section, we present the energy savings when the processor count is set equal to the baseline allocation, i.e., 2-big cores. The results are shown in Figure 10 where the x-axis shows different workloads, and the y-axis represents the percentage energy savings that are computed with respect to the energy consumption of Race-to-Idle scheme. Three schemes, i.e., Oracle, DSA, and Task-RM, are represented through bar graphs, as indicated in the legend. As expected, Oracle is shown to have maximum energy savings, i.e., 36.66% on average. Our proposed Task-RM scheme performs very close to Oracle with energy savings of 33.55% on average, showing its effectiveness in harnessing the energy savings on offer. The DSA scheme shows an energy saving of 15.11% with respect to Race-to-Idle . Moreover, Task-RM provides approximately 22% more energy savings compared to DSA .

The energy savings for various workloads show a big variation. As discussed earlier in Section 2, one of the sources of energy savings is the deviation of the execution time of the task from the UBET of that same task (i.e., early finish). To verify this reasoning, we derive a box plot of the execution times of the tasks in Figure 11. Here, the execution times are normalized to the UBETs of the tasks. A box in a boxplot represents the interquartile range (IQR), i.e., the 25th to 75th percentile, and the orange line in the box represents the median . The top end of the box in the boxplot represents the third quartile (Q3). Similarly, the bottom end of the box represents the first quartile (Q1).

The upper and lower whisker are at \(\text{Q3} + 1.5\times \text{IQR}\) and \(\text{Q1} - 1.5 \times \text{IQR}\), respectively. The range between the lower whisker to Q1 represents the lower 25th percentile, and the range between Q3 to the upper whisker represents the last upper 25th percentile. If more samples, i.e., task execution times, are far below one, i.e., UBET, the more energy savings will be on offer as more tasks have slack that can be used to slow down the execution.

Examining the boxplot, one can find a correlation between the execution time distribution and energy savings of the tasks. For example, SparseLU13 have most of the samples pretty close to UBETs and thus have relatively small energy savings, i.e., 12.49% for Oracle and 6.03% for Task-RM. Similarly, the box plot shows that execution times of SparseLU20-50 lie close to their UBET (i.e., upper whisker to lower whisker lie between 0.9 and 1 on the y-axis). This means that there isn’t a lot of available slack for these particular benchmarks and, consequently, they show relatively low energy savings.

On the other hand, for example, gauss-antoniu has most of the samples (i.e., IQR, the lower whisker to Q1, Q3 to the upper whisker) around 0.5 approximately. This means that most of the tasks have 50% slack. The energy savings of 54.85% for Oracle and 54.11% for Task-RM endorse the hypothesis that farther the tasks’ execution times from UBET more will be energy savings (see Figure 10). The remaining benchmarks, i.e., gauss-tesgrind2 – redblack2, also show similar behavior where most of their task execution times are far less than their respective UBETs (as evident from the box plot). Thus, they have far higher energy savings. Therefore, it is fair to conclude that the more significant deviation is between the UBET and execution time, the more energy savings will be on offer.

In the same context, the DSA scheme consumes more energy than race-to-idle for benchmarks that have less available slack, i.e., SparseLU13-50, and performs better for the benchmarks with more available slack. The reason behind it is the high overheads involved in repeatedly determining task descendants and applying static scheduling algorithms for slack re-allocation at run-time. If higher energy saving is available, it can offset the overhead, but if the available slack is limited, less energy saving is on offer, and hence the overheads can offset the savings resulting in higher energy consumption. One key factor in this regard is the size of the DAG, as it affects the number of descendants in each step and thus affects the overheads. This is the reason why DSA performs worst for the “SparseLU 50” workload as it has the biggest DAG with 5,550 tasks and very low (i.e., \(\approx\)10%) slack as shown in the box plot.

The accuracy of the timing and energy prediction mechanism is key to analyze the effectiveness of the proposed Task-RM scheme, so the prediction accuracy is presented in Figure 12. Here, the workloads are depicted on the x-axis and the percentage accuracy is depicted on the y-axis. The accuracy is computed by using \(\textrm {“Accuracy} (\%) = 100 \times (1 - \text{ABS} (1 - \frac{ \textrm {X}_{\textrm {predicted}} }{\textrm {X}_{ \textrm {real} } }))\)” equation, where \(X_\text{real}\) and \(X_\text{predicted}\) represent the real and predicted values, respectively, and abs() means the absolute function.

Energy and timing predictions show a considerable high accuracy with an average of 95% and 93% for timing and energy predictions, respectively. Please note that the prediction accuracy depends on the variance in task execution times. If execution times are spread over a large range, predictions will be less accurate and vice-versa. Comparing the boxplot in Figure 11 and prediction accuracy in Figure 12, one can draw some correlations. For example, the IQR range (shown by the box) is pretty narrow for most benchmarks except gauss-testgrind and gauss-testgrind-regions . Therefore, the prediction efficiency for gauss-testgrind (Timing-90%, Energy-87%) and gauss-testgrind-regions (Timing-89%, Energy-80%) is minimum among the workload set and below average.

In this section, the ability of various schemes to finish close to the application deadline is analyzed as shown in Figure 13. Here, the percentage of slack normalized to the application deadline i.e., \(100 \times \frac{T_\text{deadline} - T_\text{completion}}{T_\text{deadline}}\) is presented on the y-axis, and the x-axis shows the workloads. As expected, Oracle mostly finishes close to the deadline with an average percentage slack of 0.26%, and Task-RM performs well with an average of -0.74% that means Task-RM misses the deadline by a small margin. The race-to-idle scheme finishes way before the deadline (i.e., average slack of 24%) as this scheme does not consider slowing down to save energy. It is interesting to correlate that workloads showing the lowest timing and energy prediction accuracy, i.e., gauss-testgrind and gauss-testgrind-regions miss the deadline by the highest margins, i.e., \(-\)3.11% and \(-\)4.85%, respectively. Thus, it is fair to conclude that the execution behavior of the tasks affects the prediction accuracy and, consequently, affects the energy savings and deadline accomplishment. However, since the Task-RM is continuously adjusting the resource allocation, it effectively mitigates the loss of efficiency to finish close to the programs’ deadline and saves considerable energy.

The proposed Task-RM scheme has minimal overheads owing to its hybrid approach, where most of the analysis is carried out offline, and resource allocation is done at run-time as shown in Figure 14. The timing and energy overheads of the Task-RM scheme are 0.6% and 0.7% compared to the execution time and energy consumption, respectively. In contrast, the DSA scheme shows average timing and energy overhead of 9% and 6%, respectively. The significantly higher overheads of DSA are due to the repeated application of static scheduling algorithms. Thus, static scheduling algorithms, i.e., DSA, are not suitable for runtime use, and our scheme Task-RM is much better in limiting the overheads while providing significant energy savings.

Next, we evaluate the energy savings with the allocation of additional processors. The results are shown in Figure 15. Here the x-axis shows the processor allocations, and the y-axis represents the percentage of energy savings. The labels on the x-axis represent the processor allocation, where “B” and “L” stand for big and LITTLE cores, respectively. The number after the letters “B” and “L” represents the processor count, and for example, label B4L2 means an allocation of four big and two LITTLE cores. The core allocations are sorted in increasing number of cores, and energy savings increase as more cores are allocated, but they saturate at B8L4 with maximum energy savings of 58.8% for Oracle and 55.6% for Task-RM, respectively. Note that the availability of additional cores only increases energy savings if there are ready tasks to execute (i.e., parallelism in DAG). That is the reason that energy savings almost saturates beyond an allocation of four (i.e., B4L0) or six cores (i.e., B4L2).

The DSA scheme is unable to use additional processor allocation for energy savings as it sticks to the processor allocation from the off-line schedule and only modifies the DVFS settings. Hence, the energy savings for the DSA are the same as for the baseline processor allocation. However, as shown in Figure 15, DSA has diminishing energy savings in comparison to the race-to-idle (RTI) scheme when additional “LITTLE” cores are allocated. The reason for this is that the energy consumption for RTI changes with increased processor allocation. Remember that RTI uses all the available cores at the highest frequency. The energy consumption at the highest frequency on the “LITTLE” core is less than the energy consumption of the same task at the highest frequency on the “big” core. Thus, with the allocation of additional “LITTLE” cores, race-to-idle energy consumption tends to reduce. In contrast, the energy consumption of DSA remains the same; thus, the energy savings diminish.

The energy savings remain the same for the case when only additional “big” cores are allocated to the RTI, i.e., “B4L0” and “B8L0”. However, DSA performs worse compared to RTI for the processor allocations with more “LITTLE” cores than “big” cores, e.g., “B2L6”, “B2L8”. This is understandable as the more the “LITTLE” cores, the less the energy consumption of the RTI; consequently, the DSA scheme will have more energy consumption. This fact that energy consumption of the RTI decreases with allocation of additional “LITTLE” cores further strengthens the effectiveness of our scheme, i.e., Task-RM, as it consistently performs better.

In short, the evaluation shows that our proposed scheme Task-RM is effective in exploiting energy savings (33%) of the Oracle (36%) with negligible overheads. Task-RM performs considerably better (i.e., 22%) than run-time use of static scheduling algorithms as proposed by DSA . Moreover, the allocation of extra processors provides additional opportunities to save energy, and the ability of Task-RM to adjust to these changes is critical to the objective of saving energy. Other state-of-the-art schemes, i.e., DSA lack the ability to harness the opportunities that arise with additional processor allocation. Offline analysis of these situations allows the compilation of a LFT table that enables such intelligent resource allocation at run-time without the need for re-scheduling or re-computation of the LFT-table.