PAStime: Progress-aware Scheduling for Time-critical Computing
PPAStime: Progress-aware Scheduling forTime-critical Computing
Soham Sinha
Department of Computer ScienceBoston University
Boston, [email protected]
Richard West
Department of Computer ScienceBoston University
Boston, [email protected]
Abstract —Over-estimation of worst-case execution times(WCETs) of real-time tasks leads to poor resource utilization.In a mixed-criticality system (MCS), the over-provisioning ofCPU time to accommodate the WCETs of highly critical taskscan lead to degraded service for less critical tasks. In this paper,we present PAStime, a novel approach to monitor and adapt theruntime progress of highly time-critical applications, to allowfor improved service to lower criticality tasks. In PAStime, CPUtime is allocated to time-critical tasks according to the delays theyexperience as they progress through their control flow graphs.This ensures that as much time as possible is made available toimprove the Quality-of-Service of less critical tasks, while high-criticality tasks are compensated after their delays.In this paper, we integrate PAStime with Adaptive Mixed-criticality (AMC) scheduling. The LO-mode budget of a high-criticality task is adjusted according to the delay observed atexecution checkpoints. Using LITMUS RT to implement bothAMC and AMC-PAStime, we observe that AMC-PAStime sig-nificantly improves the utilization of low-criticality tasks whileguaranteeing service to high-criticality tasks. I. I
NTRODUCTION
In real-time systems, computing resources are typicallyallocated according to each task’s worst-case execution time(WCET), to ensure timing constraints are met. However,worst-case conditions for an application are rather rare, result-ing in poor resource utilization. Previous research work [49]shows that the worst-cases lie at the tiny tail-end of theprobability distribution curve of the execution times for manyprograms. Instead, average-case execution times are signifi-cantly more likely, taking a fraction of the worst-case times.Mixed-criticality systems (MCSs) provide a way to avoidover-estimation of resource needs, by considering the schedu-lability of tasks according to different estimates of theirexecution times at different criticality or assurance levels [48].Higher criticality tasks are afforded more execution time atthe cost of less time for lower criticality tasks, when it isimpossible to meet all task timing constraints. There have beenmultiple proposals [9], [10], [14], [18] since Vestal’s work onMCSs [48]. Most prior work focuses on meeting task dead-lines and ignores Quality-of-Service (QoS) metrics [47] suchas frames-per-second or average utilization. Although timelycompletion is most important for high-criticality applications,QoS is a significant metric for lower criticality tasks [13],[37], [44]. This has motivated our work on PAStime ( P rogress- A ware S cheduling for time -critical computing), to maximizethe QoS for low-criticality tasks.In PAStime, we first identify a checkpoint in a high-criticality application at an intermediate stage in its sourcecode. The application is then profiled offline to measurethe time to reach the marked checkpoint. Using this timingdata, the application evaluates its progress at the checkpointduring runtime. Based on the delay at the checkpoint, PAStimepredicts the expected execution time of a high-criticality appli-cation. We consequently adjust the runtime of the application,given that the change does not hamper schedulability of co-running tasks. If at runtime, a highly critical program isdeemed to be making insufficient progress, it is given greaterCPU time.We combine PAStime with Adaptive Mixed-criticality(AMC) scheduling [10], to improve the performance of low-criticality tasks. In AMC, the system is started in LO-mode ,where all tasks are scheduled with their LO-mode budgets.When a high-criticality task runs for more than its LO-modebudget, the system is switched to
HI-mode . In HI-mode,all low-criticality tasks are stopped, and the high-criticalitytasks are given their increased HI-mode budgets. However,switching to HI-mode should be avoided as much as possible[8], because it affects the performance of low-criticality tasks,which are not executed in HI-mode.Several works extend the mixed-criticality task model toimprove the performance of low-criticality tasks, such asproviding an offline extra budget allowance to the high-criticality tasks [41], and estimating multiple budgets [36],[39] and periods [42], [44] for low-criticality tasks. However,these approaches do not utilize runtime information.We extend AMC with PAStime to avoid mode switches,by dynamically adjusting the LO-mode budget for a high-criticality task, based on progress to execution checkpoints.Then, we predict the expected execution time of a high-criticality task based on the observed delay until a checkpoint.We carry out an efficient online schedulability test to determinewhether we can increase the LO-mode budget of the delayedhigh-criticality task to our predicted execution time. In casethe taskset is still schedulable with the increased budget, weextend the LO-mode budget of the high-criticality task to thepredicted execution time. When a high-criticality task finishes1 a r X i v : . [ c s . O S ] A ug ithin its extended execution budget, we keep the systemin LO-mode and avoid a mode switch that would otherwisehappen in AMC scheduling. Thus, PAStime improves the QoSof low-criticality tasks by keeping the system in LO-mode fora longer time.Factors such as I/O events and hardware micro-architecturaldelays lead to actual execution times exceeding those predictedby PAStime. Any high criticality task running at the end of itspredicted execution time causes a timer interrupt to switch thesystem into HI-mode, as is the case with AMC scheduling.Thus, a high-criticality task never misses its deadline. Contributions:
The central idea of PAStime is to helpthe OS make scheduling decisions based on a program’sruntime progress. We implement both AMC and a PAStimeextension to AMC scheduling in LITMUS RT [12], [16]. Wetest our implementation with real-world applications: an objectclassification application from the Darknet neural networkframework [40], and an MPEG video decoder [2].We show that PAStime increases the average utilization oflow-criticality tasks by 1.5 to 9 times for 2 to 20 tasks. Wealso demonstrate that our implementation of AMC-PAStimehas minimal and bounded additional overhead in LITMUS RT .We provide a C library for PAStime to instrument check-points in high-criticality programs. In addition, we modifythe LLVM compiler [30] to automatically identify potentiallocations of checkpoints during profiling for simple time-critical applications.The next section describes our approach to PAStime. Sec-tion III details the theoretical background behind AMC andits extension with PAStime. Section IV describes the designand implementation of PAStime, which is then evaluatedin Section V. Finally, we describe related work, followedby conclusions and future work in Sections VI and VII,respectively. II. A PPROACH
Compiler infrastructures such as LLVM are capable ofproducing a program’s control flow graph (CFG). A CFGrepresents the interconnection between multiple
Basic Blocks(BBs) , where a block is a sequence of straight-line code with-out any internal branches. However, CFGs are not typicallyutilized by an OS to manage time for different computingresources, in spite of being a rich source of analytical in-formation about a program. Consequently, current OSs areoblivious to a program’s computing requirements (e.g., CPUutilization) at different points in its execution. A developer ofan application can, instead, help the OS make decisions relatedto resource management, by providing runtime informationabout a program at certain points in its source code.PAStime dynamically decides a program’s execution budgetbased on its runtime progress and theoretical analysis of theallowable delay at specific checkpoint locations. At runtime,PAStime measures the time to reach a checkpoint from thestart of a task, and then compares that time to a pre-profiledreference value. The execution budget for the task is thenadjusted according to actual progress. Fig. 1: CFG and average estimates of a program
BB1:startBB2:for loop (10 times)BB3 BB6:for loop(20 times)
BB5
BB4BB7 BB8
Figure 1 shows the CFG for a program with two loops,starting at BB2 and BB6. In this example, PAStime inserts acheckpoint between the two loops at the end of BB5. BB5 isa potentially good location for a checkpoint because there isone loop before and after this BB, providing an opportunityto increase the execution budget to compensate for the delayuntil BB5.Suppose that we derive the LO-mode budget of the wholeprogram to be 2000 ms by profiling, and the time to reach thecheckpoint at BB5 is 500 ms. The program is then executedin the presence of other tasks. The execution budget at thecheckpoint (in BB5) is adjusted, to account for the program’sactual runtime progress. For example, at the checkpoint inBB5, suppose the program experiences a delay of ms. Thismeans that the checkpoint in BB5 is reached in ms, insteadof the expected ms. Therefore, the program is delayedby ( × =) 20%. Then, we predict the total executiontime of 2000 ms to be ( × =) 2400 ms. Thisis based on the runtime information until the checkpoint inBB5 which has shown a delay of 100 ms. Hence, we need toincrease the program’s execution budget by 400 ms. PAStimeuses this available information until a checkpoint to extend theLO-mode budget of a high-criticality application. A. Benefits in Adaptive Mixed-criticality Scheduling
We see progress-aware scheduling as being beneficial inmixed-criticality systems. Adaptive Mixed-criticality schedul-ing [10] is the state-of-the-art fixed-priority scheduling policyfor Mixed-criticality tasksets. In AMC, a system is firstinitialized to run in
LO-mode . In LO-mode, all the tasks areexecuted with their LO-mode execution budgets. Whenever ahigh-criticality task overruns its LO-mode budget, the systemis switched to
HI-mode . In HI-mode, all low-criticality tasksare discarded (or given reduced execution time [8], [36]), andthe high-criticality tasks are given increased HI-mode budgets.The system’s switch to HI-mode therefore impacts the QoS forlow-criticality tasks.By combing PAStime with AMC (to yield AMC-PAStime),we extend the LO-mode budget of a high-criticality task toits predicted execution time at a checkpoint. Going back toour previous example in Figure 1, we try to extend the LO-mode budget of the task by 400 ms. We carry out an online2chedulability test to determine if we can extend the task’sLO-mode budget by 400 ms. If the whole taskset is stillschedulable after an extension of the LO-mode budget ofthe delayed high-criticality task, the increment in the task’sLO-mode budget is approved. We let the task run until theextended time and keep the system in LO-mode. In case thehigh-criticality task finishes within its extended time, we avoidan unnecessary switch to HI-mode. Thus, the low-criticalitytasks run for an extended period of time and do not sufferdegraded CPU utilization and QoS, as occurs with AMC.In case the task does not finish within the predicted time,then the system is changed to HI-mode, and low-criticalitytasks are finally dropped. This behavior is identical to AMC,and every high-criticality task still finishes within its owndeadline. Therefore, we improve the QoS of the low-criticalitytasks when the high-criticality tasks finish within their ex-tended LO-mode budgets, and otherwise, we fall back toAMC. When there is no delay at a checkpoint, we do notchange a task’s LO-mode budget.III. T
HEORETICAL B ACKGROUND
In this section, we provide a response time analysis forAMC-PAStime by extending the analysis for AMC scheduling.We also describe details about the online schedulability testbased on the response time values.
A. Schedulability Analysis for AMC and PAStime1) Task Model:
We use the same AMC task model asdescribed by Baruah et al [10]. Without loss of generality,we restrict ourselves to two criticality levels - LO and HI.Each task, τ i , has five parameters: C i ( LO ) - LO-mode runtimebudget, C i ( HI ) - HI-mode runtime budget, D i - deadline, T i - period, and L i - criticality level of a task, which is eitherhigh ( HC ) or low ( LC ). We assume each task’s deadline, D i , is equal to its period, T i . A HC task has two budgets: C i ( LO ) for LO-mode assurance and C i ( HI ) ( > C i ( LO )) for HI-mode assurance. A LC task has only one budget of C i ( LO ) for LO-mode assurance.
2) Scheduling Policy:
Both AMC and AMC-PAStime usethe same task priority ordering, based on Audsley’s priorityassignment algorithm [5]. If a task’s response time for a givenpriority order is less than its period, then the task is deemedschedulable. The details of the priority assignment strategyare discussed in previous research work [6], [10]. We do notchange the priority ordering of the tasks at runtime.AMC-PAStime initializes a system in LO-mode with alltasks assigned their LO-mode budgets. We extend a high-criticality task’s LO-mode budget at a checkpoint if the task islagging behind its expected progress, as long as the extensiondoes not hamper the schedulability of the delayed task andall the lower or equal priority tasks. An increase to the LO-mode budget of a task that violates its own or other taskschedulability is not allowed. If a high-criticality task has notfinished its execution even after its extended LO-mode budget,then the system is switched to HI-mode.
3) Response Time Analysis:
The AMC response time recur-rence equations for (1) all tasks in LO-mode, (2) HC tasks inHI-mode, and (3) HC tasks during mode-switches are shownin Equation 1, 2 and 3, respectively. hp ( i ) is the set of taskswith priorities higher than or equal to that of τ i . Likewise, hpHC ( i ) and hpLC ( i ) are the set of high- and low-criticalitytasks, respectively, with priorities higher than or equal to thepriority of τ i .AMC provides two analyses for mode switches: AMC-response-time-bound (AMC-rtb) and AMC-maximum. We useAMC-rtb for our analysis, as AMC-maximum is computa-tionally more expensive. However, AMC-rtb does not allowa taskset which is not schedulable by AMC-maximum. There-fore, AMC-rtb is sufficient for schedulability. R LOi = C i ( LO ) + (cid:88) τ j ∈ hp ( i ) (cid:100) R LOi T j (cid:101) × C j ( LO ) (1) R HIi = C i ( HI ) + (cid:88) τ j ∈ hpHC ( i ) (cid:100) R HIi T j (cid:101) × C j ( HI ) (2) R ∗ i = C i ( HI ) + (cid:88) τ j ∈ hpHC ( i ) (cid:100) R ∗ i T j (cid:101) × C j ( HI )+ (cid:88) τ j ∈ hpLC ( i ) (cid:100) R LOi T j (cid:101) × C j ( LO ) (3)With AMC-PAStime, if a high-criticality task, τ i , is delayedby X % at a checkpoint, compared to its pre-profiled progress,then τ i ’s budget is tentatively increased from C i ( LO ) to C (cid:48) i ( LO ) . C (cid:48) i ( LO ) = (cid:0) C i ( LO ) + C i ( LO ) × X (cid:1) . An onlineschedulability test then calculates the the extended LO-moderesponse time, R LO -ext i , for τ i , using Equation 4. Similarly, R ∗ -ext i is calculated using Equation 5. Equations 4 and 5 areextensions of Equations 1 and 3. AMC-PAStime checks atruntime whether both R LO -ext i and R ∗ -ext i are less than or equalto τ i ’s period to determine its schedulability.The new response times are then calculated for all tasksin LO-mode with priorities less than or equal to τ i , usingEquation 4. Similarly, new response times are calculated forall HC tasks with lower or equal priority to τ i during a modeswitch, using Equation 5. If all newly calculated responsetimes are less than or equal to the respective task periods, thesystem is schedulable. In this case, AMC-PAStime approvesthe LO-mode budget extension to τ i . If the system is notschedulable, then τ i ’s budget remains C i ( LO ) . R LO -ext i = C (cid:48) i ( LO ) + (cid:88) τ j ∈ hp ( i ) (cid:100) R LO -ext i T j (cid:101) × C (cid:48) j ( LO ) (4) R ∗ -ext i = C i ( HI ) + (cid:88) τ j ∈ hpHC ( i ) (cid:100) R ∗ -ext i T j (cid:101) × C j ( HI )+ (cid:88) τ j ∈ hpLC ( i ) (cid:100) R LO -ext i T j (cid:101) × C j ( LO ) (5)3MC-PAStime only extends the LO-mode budget of adelayed HC task for its current job. When a new job for thesame HC task is dispatched, it starts with its original LO-modebudget. If another request for an extension in LO-mode forthe same task appears, AMC-PAStime tests the schedulabilitywith the maximum among the requested extended budgets.The system keeps track of the maximum extended budget fora task and uses that value for online schedulability testing.We explain the AMC-PAStime scheduling scheme with anexample taskset in Table I.TABLE I: A mixed-criticality taskset example Task Type C(LO) C(HI) T Pr R LO R ∗ τ HC 3 6 10 1 3 6 τ LC 2 - 9 2 5 - τ HC 5 10 50 3 15 38
Suppose, task τ is delayed by 66% at a checkpoint in thetask’s source code. PAStime will then try to extend the budgetby (3 × ) ≈ time units. Therefore, the potential extendedbudget C (cid:48) ( LO ) for τ would be (3 + 2) = 5 time units.PAStime will calculate the response times, R LO -ext i and R ∗ -ext i ,for τ and the lower priority tasks τ and τ . R LO -ext wouldjust be 5, and R ∗ -ext would remain the same as R ∗ = 6 , as τ is the highest priority task. The new R LO -ext would be 7 (byEquation 4) which is smaller than its period of 9. Therefore, τ would still be schedulable if we extend τ ’s LO-mode budgetfrom 3 to 5.For τ , the new R LO -ext and R ∗ -ext would be, respectively, 26(by Equation 4) and 40 (by Equation 5) which are also smallerthan τ ’s period of 50. Therefore, the extended budget of for τ would be approved by AMC-PAStime. In conventionalAMC scheduling, the system would be switched to HI-mode if τ did not finish within 3 time units. However, AMC-PAStimewill extend τ ’s LO-mode budget to 5 because of the observeddelay at its checkpoint, so the system is kept in LO-mode.Consequently, LC task τ is allowed to run by AMC-PAStime,if τ finishes before 5 time units. If τ does not finish evenafter 5 time units, the system would be switched to HI-mode.In this example, 5 jobs of τ are dispatched for every singlejob of τ , as τ ’s period of 50 is 5 times the period of τ .Suppose τ asks for the 66% increment in its LO-mode budgetfor the first job, as we have explained above. In its second job, τ asks for an increment of 33% (1 time unit) in its LO-modebudget. In this case, we again need to calculate the responsetimes for all tasks. If we calculate the online response times for τ and τ assuming (3 + 1) = 4 time units for C (cid:48) ( LO ) , thenwe would not account for the first job of τ , which potentiallyexecutes for 5 time units. We would need to keep track of theextended LO-mode budgets for all jobs of τ , to accuratelycalculate online response times for τ and τ .To avoid the cost of recording all extended LO-modebudgets for a task, AMC-PAStime simply stores the max-imum extended budget for a task. When calculating onlineresponse times to check whether to approve an extension tothe LO-mode budget, the system uses the maximum extended budget of every high-criticality task. This value is stored inthe max_extended_budget variable for each HC task.Therefore, when τ asks for time units as its extended LO-mode budget in its second job, the system calculates R LO -ext , R ∗ -ext , R LO -ext , R LO -ext , R ∗ -ext with C (cid:48) ( LO ) = 5 .AMC-PAStime uses maximum extended budgets to cal-culate safe upper bounds for online response times. The max_extended_budget is reset when a task has notrequested a LO-mode budget extension for any of its jobsdispatched within the maximum period of all tasks. B. Online Schedulability Test
AMC-PAStime performs an online schedulability test when-ever a high-criticality task asks for an extension to its LO-mode budget. The test calculates the response times ( R LO -ext i and R ∗ -ext i ) of the delayed high-criticality task and all lowerpriority tasks. Then, it checks whether the response times areless than or equal to the task periods. If any task’s responsetime is greater than its period, the online schedulability testreturns false, and the extension in LO-mode for the high-criticality task is denied. If the schedulability test is successfulthe high-criticality task is permitted to run for its extendedbudget in LO-mode.
1) Initial Value for Online Response Times Calculation:
Online response time calculations may take significant time,depending on the number of iterations of Equations 4 and 5.However, the response time values from Equations 1, 2, 3 arealready calculated offline to determine the schedulability of ataskset using Audsley’s priority assignment algorithm [5] withAMC scheduling. Since AMC-PAStime uses the same priorityordering as AMC scheduling, the offline response times forschedulability remain same.AMC-PAStime initializes the online R LO -ext i in Equation 4with R LOi + e , where R LOi is calculated offline by Equation 1and e ( > is the extra budget of the delayed task. e is set to C i ( LO ) × X if τ i is delayed by X % at its checkpoint.Since the budget of a delayed task is extended by e , R LO -ext i must be greater than or equal to R LOi + e . Hence, this is a goodinitial value to start calculating R LO -ext i online. In Section V,we establish an upper bound on the total number of iterationsneeded to check the schedulability of random tasksets, if thehighest priority task’s budget is extended by different amounts.
2) Details of the Online Test:
Algorithm 1 is the pseu-docode for the online schedulability test. The offline responsetime values ( R LOi and R ∗ i ) are stored in the timing propertiesfor each task τ i . When a high-criticality task τ k is delayed, itasks for an extension of its LO-mode budget by e time units.Line 6 in Algorithm 1 determines whether the newly re-quested extension, e , is more than a previously saved maxi-mum extended budget for τ k . In lines 10–13, the C (cid:48) i ( LO ) isset to the maximum extended budget for all the lower prioritytasks and τ k . As we have explained above, it is practicallyinfeasible to store the execution times of every job of all thetasks to calculate online response times. Therefore, we storethe maximum extended budget of every task and use this tocalculate response times online. For the currently delayed task,4 k , C (cid:48) k ( LO ) is set to the maximum value of a previouslysaved max_extended_budget and the currently requested C k ( LO ) + e . Considering the example in Table I, line 12would translate to C (cid:48) i ( LO ) =max(5, 4) for the second LO-modeextension request.Then, Equation 4 is solved in line 15 by initializing R LO -ext i to the R LOi plus extra budget e (cid:48) from line 6. If a lowerpriority task is a high-criticality task, then R ∗ -ext i is calculatedin line 19, with the newly derived value of R LO -ext i .The initial value in the recurrence relations is set offline to significantly decrease the number of online iterations, andhence overhead, needed to determine taskset schedulability.In addition, we solve both recurrence relations with an incre-mental response time algorithm [17] to further minimize theoverhead. Algorithm 1
Online Schedulability Test Input: tasks - set of all tasks in priority order τ k - delayed task e - extra budget for τ k Output: true or f alse function I S B UDGET C HANGE A PPROVED ( tasks , τ k , e ) e (cid:48) = max ( τ k . max_extended_budget , C k ( LO ) + e ) − C k ( LO ) for each task τ i in { τ k ∪ lower priority tasks than τ k in tasks } do C (cid:48) i ( LO ) = τ i . max_extended_budget if τ i is τ k then C (cid:48) i ( LO ) = max ( C (cid:48) i ( LO ) , C i ( LO ) + e ) end if Initialize R LO -ext i for Equation 4 with R LOi + e (cid:48) Solve Equation 4 if R LO -ext i ≤ T i then if τ i is high-criticality then Initialize R ∗ -ext i for Equation 4 with R ∗ i Solve Equation 5 with the new R LO -ext i if R ∗ -ext i > T i then Return f alse end if end if else Return f alse end if end for τ k . max_extended_budget = max( C k ( LO ) + e, τ k . max_extended_budget) Return true end function
IV. D
ESIGN AND I MPLEMENTATION OF
PAS
TIME
In this section, we first describe the overall design ofAMC-PAStime in LITMUS RT [12], [16]. This is followedby a description of how checkpoints are instrumented in anapplication’s source code. We then show the algorithm todetermine and insert checkpoints, which is integrated intothe LLVM compiler infrastructure. A high-criticality taskrequires profiling to determine the placement of checkpoints, before it is ready for execution with other tasks. We describehow the profiling and execution of a high-criticality task isperformed, along with the scheduling mechanism in PAStime.The source code for PAStime in LITMUS RT will be madepublicly available. A. Design Overview
AMC-PAStime has two phases: a Profiling phase for high-criticality tasks, and an Execution phase. In the Profilingphase, one or more checkpoints are placed at key stages ina program’s source code. The average time to reach eachcheckpoint is then measured. After profiling all high-criticalitytasks, the system switches into the Execution phase. The timetaken to reach each checkpoint in every high-criticality task isobserved by the system at runtime. Each observed time is com-pared against the profiled time to reach the same checkpoint.Any high-criticality task lagging behind its profiled time toa checkpoint is tentatively given increased LO-mode budget,according to the approach described in Section III.Fig. 2: Implementation of AMC-PAStime in LITMUS RT c . Returns spent budget Compile b . At a checkpoint, asks how much budget is spent Application Source Code Checkpoint-ed Executable for profiling Run Checkpoint timing data in a header fileCheckpoint-ed Executable for deployment Compile LITMUS RT Kernel Execute a . Starts running a job4 d . Compares with reference in header file and asks for LO-mode extension, if needed4 f . Finishes a job 4 e . Approves or disapproves (Execution phase) (Profiling phase) Figure 2 shows an overview of the design of AMC-PAStimein LITMUS RT . Step 1 is the compilation of a high-criticalityapplication’s source code in the Profiling phase, which usesour compilation procedure [38]. The compiled executable hascheckpoints embedded into its code for profiling. Step 2executes the program to generate timing metadata for eachcheckpoint in a timeinfo.h file. Step 2 is performed multipletimes with different program inputs to generate an averagetime to reach each checkpoint.Step 3 compiles the source code along with the checkpointtiming metadata header file ( timeinfo.h ) for the Executionphase, producing a binary image that is used for deploymentunder working conditions. Finally, Step 4 runs the code inthe Execution phase along with all other tasks. At some pointafter the system is started, Step 4a starts running a job for ahigh-criticality task. When a checkpoint is reached, Step 4basks the LITMUS RT kernel how much budget it has consumed.Step 4c returns the spent budget from the LITMUS RT kernelto the application.5fter receiving the spent budget, t spent , the application com-pares it to the reference timing, t ref , for the checkpoint fromthe timeinfo.h header file. It calculates the extra budget that itneeds in LO-mode, using Equation 6. If e > in the equation,Step 4d asks LITMUS RT for extra budget. The AMC-PAStimescheduling policy in the LITMUS RT kernel runs an onlineschedulability test using Algorithm 1. If Algorithm 1 returnstrue, the LO-mode budget of the current task is extended by e . If the algorithm returns false, the task budget is not altered.Finally, Step 4f finishes the current job of the running task. e = C i ( LO ) × ( t spent − t ref ) t ref (6) B. Checkpoint Instrumentation and Detection
A checkpoint is a key stage in an application’s code, usedto evaluate the progress of a currently running task. Wellplaced checkpoints balance the number of instructions thatare executed prior to the checkpoint, with those that remain tothe next checkpoint or the end of the program. Ideally, thereshould be a meaningful number of instructions leading up toa checkpoint to determine progress. Likewise, there shouldbe sufficient instructions after a checkpoint to increase thelikelihood that a task is adequately compensated for executiondelays using an extended budget.A developer of a high-criticality application finds a potentialcheckpoint location in the program’s source code for itsExecution phase, after trying out multiple locations in theProfiling phase. PAStime includes a development library toinstrument checkpoints for the two different phases. Additionalmodifications to the LLVM compiler [30] are used to detectand instrument checkpoints in the Profiling phase.
1) Checkpoint Library:
We have developed a C library toinstrument checkpoints in the two PAStime phases. The mainpurpose of the library is to generate the necessary checkpointtiming information during the Profiling phase and then requesta task’s extended LO-mode budget from the LITMUS RT kernelduring the Execution phase.In the Profiling phase, a noteTime function call fromour library is inserted into the application code at a desiredcheckpoint. noteTime takes a unique ID for each checkpoint.The function logs the time to reach that checkpoint in thesource code since the start of a job. The average of multiplesuch timing entries is saved in timeinfo.h after the Profilingphase.During the Execution phase, a preprocessor macro called EXTEND_BUDGET is inserted at a checkpoint. This macroobtains the spent budget from the LITMUS RT kernel viaa get_current_budget system call. Then, it comparesthe spent budget with the reference budget from the time-info.h header file, and calculates the extra budget usingEquation 6. If extra budget is needed, the macro makes a set_rt_task_param system call.
2) Manually Inserted Checkpoint:
A developer may at-tempt various strategies to identify a key stage [15], [23], [46]of an application to instrument a checkpoint. The developeruses either the noteTime function for the Profiling phase, or the
EXTEND_BUDGET macro for the Execution phase toinstrument a checkpoint. Checkpoints should generally beavoided inside tight loops. Visiting a checkpoint every loopiteration incurs a small overhead that is accumulated acrossmultiple iterations.
3) Automatic Instrumentation of a Checkpoint:
We havewritten a compiler pass in LLVM to automatically instrumentcheckpoints for the Profiling phase of PAStime. The instru-mented code is run in the Profiling phase, and multiple check-point timing information is generated. Finally, the developerchooses one such checkpoint for the Execution phase.The compiler pass automatically inserts checkpoints in thebasic block preceding each loop in a function, except the firstloop. The first loop is excluded so that enough instructions areexecuted before a checkpoint to determine meaningful delays.For nested loops, we consider only the outer loop. Au-tomatic instrumentation works with only simple programstructures and ignores intersecting loops. LLVM’s
LoopInfo analysis identifies only natural loops [3]. We utilize the
LoopInfo class in our checkpoint instrumentation imple-mentation.
Algorithm 2
Determine and Insert Checkpoints isLoopBef ore : identifies if a loop is in the paths from the starting BB to another BB visited : set of already visited BBs in DFS function INSERT C HECKPOINT (function) startingBB = f unction.getEntryBlock ()
6: DO
DFS( startingBB ) end function function DO DFS( currentBB ) if currentBB is in visited then return end if LoopID = getLoopFor( currentBB ) if LoopID != null then if isLoopBef ore [ currentBB ] ∧ isLoopHeader( currentBB ) then insert checkpoint before currentBB end if end if insert currentBB in visited for each s in successors of currentBB do
20: DO
DFS( s ) end for end function a) Checkpoint Location Algorithm: Our algorithm toidentify checkpoint locations for the Profiling phase is givenin Algorithm 2. We start a Depth First Search (DFS) from thestarting Basic Block (BB) of a function, by calling
DoDFS in line 6. We check whether a BB is part of a loop using
LoopInfo ’s getLoopFor member function. This functionreturns a unique LoopID for every new loop. An inner loopwithin a nested loop has the same ID as its outer loop. If aBB is not part of a loop, then it returns null .6f a BB is part of a loop, we first check in line 12 whetherthere is any loop before the current loop using a dictionary isLoopBefore . isLoopBefore is pre-populated for ev-ery BB in the CFG to indicate whether there is at least one loopseen in the paths from the starting BB to the current BB. Topre-populate isLoopBefore , we just check whether thereis a path to a BB from the loop BBs.Then, in Algorithm 2, we verify that the current BB isa header of a loop using LoopInfo ’s isLoopHeader member function. A header is the entry-point of a natural loop.We insert a checkpoint in the predecessor BB of a header.Finally, if there is at least one loop before the current headerBB, we add a checkpoint before the current BB in line number13. As natural loops have only one header, we avoid insertinga checkpoint for any inner loop in nested loops. We continuethe DFS by marking the current BB as visited. b) Compiler Pass: We have implemented the above algo-rithm in a compiler pass within LLVM [30], to automaticallydetect and instrument appropriate function calls as checkpointsin a C language program. This uses our previously describedCheckpoint library for the Profiling phase. A developer usesour modified LLVM compiler with their high-criticality appli-cation written in C. Our compiler pass operates at the LLVMIntermediate Representation (IR) level. It takes a piece of IRlogic as input, figures out the points of interest according to theabove algorithm for checkpoints in a particular function, andgenerates the instrumented IR. These IRs are compiled intoexecutable machine code. As the compiler pass operates at theIR level, it is easily extensible to other high-level languagesand back-ends supported by LLVM.
C. Profiling and Execution Phases
The Profiling phase of PAStime determines viable check-points for use in the Execution phase, and also the LO-and HI-mode budgets for a high-criticality application. Acheckpointed program is run multiple times in the Profilingphase using a set of test cases. The program is allowed tohave multiple test checkpoints, which are either generatedautomatically using our modified LLVM compiler, or manuallyby a developer. Each checkpoint has a unique ID given to thecheckpoint function call noteTime . We have developed aPython package to help run the Profiling phase and collect theaverage times to reach different checkpoints.Step 4 in Figure 2 is the start of the Execution phase.One checkpoint from those generated in the Profiling phasefor a high-criticality application is instrumented with an
EXTEND_BUDGET macro. Although in general it is possibleto use multiple checkpoints within the same application in theExecution phase, our experience shows that one is sufficient toimprove LO-mode service. Multiple checkpoints add overheadto the task execution. Moreover, later checkpoints account forexecution delays that make earlier checkpoints redundant, aslong as they are reached before the LO-mode budget expires.The key issue in deciding on a single checkpoint for theExecution phase is to ensure it is not placed too late in theinstruction stream. If it is placed too far into the program code a mode switch may occur before the task’s LO-mode budget isextended due to delays. We show in Section V-D the effects ofusing checkpoints at different locations in a program’s code.
D. Implementation Details in LITMUS RT As a first step to applying PAStime for use in adaptivemixed-criticality scheduling, we extended LITMUS RT withAMC support. This required modifications to the existingpartitioned fixed-priority scheduling policy, to include thefollowing new variables in the task properties: c_lo , c_hi , r_lo , r_star , c_extended , max_extended_budget .Tasks are divided into low- and high-criticality classes. Bydefault, the HI-mode budget for low-criticality tasks, c_hi , isset to zero. If desired, we also support a reduced, non-zero HI-mode execution budget for low-criticality tasks, as discussedin the work on Imprecise Mixed-criticality scheduling [36].Task priorities are determined offline, along with all responsetimes for a system operating in LO-mode ( r_lo ) and during amode switch ( r_star ). These parameters are then initializedin the kernel when the system starts executing a set of tasks. a) Policy for mode switches: A system-wide mode isinitialized in the LITMUS RT kernel. The system is started inLO-mode, with all tasks assigned their c_lo budgets. When-ever a high-criticality task is out of its LO-mode budget, anenforcement timer handler (based on Linux’s high-resolutiontimer [34]) is fired, and the system is switched to HI-mode.For AMC-PAStime, c_extended is the extended LO-mode budget for a delayed job of a high-criticality task. Anenforcement timer handler is therefore triggered only when ahigh-criticality task is still unfinished after the depletion of it c_extended time.As Baruah et al. suggest [10], an AMC system switchesback to LO-mode when none of the high-criticality tasks havebeen running for more than their LO-mode budgets. In the caseof AMC-PAStime, the system will switch to a lower criticalitylevel when none of the high-criticality tasks have been runningfor more than their extended LO-mode budgets. A list is usedto keep track of which high-criticality tasks complete withintheir (extended) LO-mode budgets, to determine when to revertto a lower system criticality level. b) LO-mode Budget Extension: A task’s LO-mode budget is extended by AMC-PAStime by makinga set_rt_task_param system call inside the
EXTEND_BUDGET macro. We have implemented the task_change_params callback of a LITMUS RT sched_plugin interface to support runtime adjustment oftask parameters. In the task_change_params callback,the system runs an online schedulability test according toAlgorithm 1. If the test returns true , the budget extensionis approved, and the enforcement timer for the current taskis adjusted accordingly. The task’s c_extended variableis updated, along with the maximum value of its extendedbudget in max_extended_budget .V. E VALUATION
We test our implementation of AMC and AMC-PAStimein LITMUS RT with real-world applications on an Intel NUC7it [25]. The machine has an Intel Core i7-5557U 3.1GHzprocessor with 8GB RAM, running Linux kernel 4.9. Weuse two real-world applications in our evaluations: a high-criticality object classification application from the Darknetneural network framework [40], and a low-criticality MPEGvideo decoder [2]. These applications are chosen for theirrelevance to the sorts of applications that might be used ininfotainment and autonomous driving systems.For object classification, we use the COCO dataset [33]images for both profiling and execution. For the video decoderapplication, we use the Big Buck Bunny video [1] as the input.We have turned off memory locking with mlock by the user-space liblitmus library, as multiple object classificationtasks collectively require more RAM than the physical 8GBmachine limit.
A. Task Parameters
Table II shows the LO- and HI-mode budgets for the twoapplications. Each object classification task consists of a seriesof jobs that classify objects in a single image. Each videodecoder task decodes 30 frames in a single job.TABLE II: Applications and their budgets
Application C(LO) C(HI) object classification 345 ms 627 msvideo decoder 250 ms -
The LO-mode budget, C ( LO ) , is the average time that atask takes to complete its job. In Section V-C, we also presentexperiments where we increase our LO-mode budget estimate.The HI-mode budget, C ( HI ) , accounts for the worst-caserunning time of the high-criticality task for any of its jobs.The LO-mode utilization of each individual task is generatedby the UUnifast algorithm [11]. We then calculate a task’speriod by dividing its LO-mode budget by its utilization.Figure 3 shows the maximum execution times of 10 high-criticality object classification tasks in the presence of 10 otherlow-criticality video decoder tasks. We see that none of thetasks exceed the HI-mode budget of ms, which is also thecase in all subsequent experiments. Consequently, none of thehigh-criticality tasks miss their deadlines in any of our tests.Fig. 3: Object classification Task ID M a x . E x e c u t i o n T i m e ( m s ) HI-mode budgetAMC-PAStime AMC
Fig. 4: Switches to HI-mode
30 60 90 120 150 180
Seconds C u m u l a t i v e o f m o d e s w i t c h e s AMCAMC-PAStime
B. QoS Improvements for Low-criticality Tasks
We compare the QoS for low-criticality tasks using AMCand AMC-PAStime in different cases. In every case, each taskset has an equal number of high-criticality object clas-sification tasks and low-criticality video decoder tasks. Weexperiment with ten schedulable tasksets in all cases exceptthe base case described below. We run each of the tests tentimes, and we report the average of the measurements for low-criticality tasks. As stated earlier, all high-criticality tasks meettheir timing requirements in each case.
1) Base Case - Two Tasks:
Our base case is to run onehigh-criticality object classification task and one low-criticalityvideo decoder task for 180 seconds. Here, we set the periodsof both tasks to 1000 ms rather than using the UUnifastalgorithm, yielding a total LO-mode utilization of ~60%.Figure 5a shows the cumulative number of frames decodedby the video decoder task. The LO-mode Upper Bound (UB)line shows the cumulative number of decoded frames ifthe system is kept in LO-mode for the full 180 seconds.This line represents a theoretical upper bound for a decodedframe playback rate of 30 frames per second over the entireexperimental run.We see in Figure 5a that AMC-PAStime has a 9–21% in-crease in the cumulative number of decoded frames comparedto AMC scheduling. The performance of the low-criticalitytask is related to the number of HI-mode switches in thetwo scheduling policies. Figure 4 shows that AMC-PAStimedecreases the number of HI-mode switches by 35% over theentire execution run, compared to AMC scheduling.Fig. 5: Two tasks - Video Decoder performance
30 60 90 120 150 180
Seconds C u m u l a t i v e o f F r a m e s LO-mode UBAMC-PAStimeAMC (a) Cumulative number of frames
30 60 90 120 150 180
Seconds A v g U t ili z a t i o n o f L C t a s k ( % ) LO-mode UBAMC-PAStimeAMC (b) Average utilization
Although the number of decoded frames is an illustrativemetric for a video decoder’s QoS, the average utilization ofan application is a more generic metric. Average utilizationrepresents the CPU share a task receives over a period oftime. Figure 5b shows that AMC-PAStime achieves 10% moreutilization on average for the video decoder task, comparedto AMC scheduling. The LO-mode UB line is the maximumutilization of the video decoder task, which is 25% (i.e., C ( LO ) /P eriod = 250 ms/1000 ms).
2) Scalability:
To test system scalability, we increase thenumber of tasks in a taskset up to 20 tasks. As explainedabove, we generate the periods of the tasks by distributing thetotal LO-mode utilization of ~60% to all the tasks using theUUnifast algorithm. This setup is inspired by the theoreticalparameters in previous mixed-criticality research work [10].The LO-mode utilization bound for low-criticality tasks re-mains between 25–35%.8igure 6 shows the average utilization of the low-criticalitytasks, when the total tasks vary from 2 to 20. Each task in thiscase consists of 20 jobs. We see that the average utilizationdrops for AMC scheduling as the number of tasks increases.AMC-PAStime achieves significantly greater average uti-lization for the low-criticality tasks, by deferring systemswitches to HI-mode until much later than with AMC schedul-ing. This is because the LO-mode budgets for the high-criticality tasks are extended due to runtime delays.Table IIIa shows that AMC-PAStime decreases the numberof mode switches by 28–55%. AMC-PAStime’s resistanceto switching into HI-mode allows low-criticality tasks tomake progress. This in turn improves their QoS. In theseexperiments, AMC-PAStime improves the utilization of thelow-criticality tasks by a factor of , and , respectively, for8, 14 and 20 tasks.TABLE III: Number of mode switches (a) Varying number of tasks Utilization (%)
AMC AMC-PAStime
40 11 450 11 460 9 470 10 580 11 9 (b) Varying LO-mode utilization
Fig. 6: Varying A v g . U t ili z a t i o n o f L C t a s k s ( % ) AMCAMC-PAStime
Fig. 7: Varying LO-utilization
40 45 50 55 60 65 70 75 80
Initial Total LO-mode Utilization (%) A v g . U t ili z a t i o n o f L C t a s k s ( % ) LO-mode UBAMC-PAStimeAMC
3) Varying the Initial Total LO-mode Utilization:
In thistest, we vary the initial total LO-mode utilization for 8 tasksfrom 40% to 80% by adjusting the periods of all tasks. Theinitial utilization does not account for increases caused by LO-mode budget extensions to high-criticality tasks.Figure 7 demonstrates that AMC-PAStime improves averageutilization of the low-criticality tasks by more than 3 times,up to 70% total LO-mode utilization. After that, AMC-PAStime and AMC scheduling converge to the same averageutilization for low-criticality tasks. This is because there isinsufficient surplus CPU time in LO-mode for AMC-PAStimeto accommodate the extended budget of a high-criticality task.Therefore, the LO-mode extension requests are disapproved byAMC-PAStime.Table IIIb demonstrates that AMC-PAStime improves thelow-criticality tasks’ QoS by reducing the number of modeswitches by ~50% until 70% LO-mode utilization. We note that the schedulability of random tasksets de-crease with higher LO-mode utilization in AMC scheduling.Therefore, many real-world tasksets may not be schedulablebecause of their HI-mode utilizations. Thus, AMC-PAStime’simproved performance is significant for practical use-cases.Fig. 8: Overestimated C ( LO ) +0 +20 +40 +60 +70 Overestimation of LO-runtime (%) A v g . U t ili z a t i o n o f L C t a s k s ( % ) LO-mode UBAMC-PAStimeAMC
Fig. 9: Checkpoint location
Checkpoint Location o f M o d e - s w i t c h e s AMCAMC-PAStime
C. Estimation of LO-mode Budget
In our evaluations until now, we estimate a LO-mode budgetbased on the average execution time of the high-criticalityobject classification application. In the next set of experiments,we estimate the LO-mode budget of a high-criticality task tobe a certain percentage above the average profiled executiontime. An increased LO-mode budget for high-criticality tasksbenefits AMC scheduling. This is because high-criticality tasksare now given more time to complete in LO-mode, andtherefore low-criticality tasks will still be able to execute aswell. As a result, the utilization of low-criticality tasks is ableto increase.Suppose that C ( LO ) is an average execution time esti-mate for the LO-mode budget of a high-criticality task. Let ( C ( LO ) + o ) be an overestimate of the LO-mode budget. Asbefore, AMC-PAStime detects an X % lag at a checkpoint andpredicts the total execution time to be C ( LO ) + e , where e is derived from Equation 6. If the actual LO-mode budget is ( C ( LO ) + o ) then AMC-PAStime requests for an extra budgetof ( e − o ) , assuming ( e − o ) > .Figure 8 shows that AMC-PAStime still improves utilizationfor the low-criticality tasks by more than a factor of 3 up toan overestimation of 40%. Overestimation helps in reducingthe number of mode switches for AMC scheduling after 40%,as high-criticality tasks have larger budgets in LO-mode.There is no improvement by AMC scheduling after 60%LO-mode budget overestimation. AMC-PAStime also showsno benefits with increased overestimation, because the LO-mode budget extensions are disapproved by the online schedu-lability test. Therefore, the system is switched to HI-mode byan overrun of a high-criticality task. D. Checkpoint Location
We use our modified LLVM compiler in the Profilingphase to determine a viable checkpoint for the high-criticalityobject classification task. We instrument checkpoints in the forward_network function of the Darknet neural networkmodule. We consider four checkpoint locations in the Profiling9ig. 10: Prediction accuracy
Job ID E x e c u t i o n T i m e ( m s ) Predicted Actual
Fig. 11: Offline iterations
10 20 30 40 50 60 70 80
Extra LO-runtime Demand (%) o f I t e r a t i o n s ( O ff li n e ) ApprovedDisapproved
Fig. 12: Online iterations
Seconds o f I t e r a t i o n s ApprovedDisapprovedOffline Bound
Fig. 13: Budget extension O v e r head ( µ s ) MaxAverage phase, which are both automatically and manually instru-mented. In the Execution phase, we measure performancefor each of these checkpoint locations. Figure 9 shows thevariation in the number of mode switches against the locationof a checkpoint. The x-axis is the approximated division pointof a checkpoint location with respect to LO-mode budget. Forexample, 0.1 × means that the checkpoint is at (0 . × C ( LO )) .We see that the number of mode switches decreases if thelocation of a checkpoint is more towards the middle of thecode. However, a checkpoint near the start and the end of thesource code have nearly the same number of mode switches,as with AMC scheduling. A checkpoint near the beginning ofa program is not able to capture sufficient delay to increase theLO-mode budget enough to prevent a mode switch. Likewise,a checkpoint near the end of a program is often too late.A HI-mode switch may occur before the high-criticality taskeven reaches its checkpoint. Hence, a checkpoint at . × inthe source code of a program reduces the number of modeswitches by just 1. E. Effectiveness of a Checkpoint
We now investigate whether a checkpoint is effective indetecting a delayed high-criticality object classification task.We compare the predicted and actual times taken by the high-criticality tasks when LO-mode is extended by AMC-PAStime.This experiment is performed with 8 tasks for 40 jobs each.The initial total LO-mode utilization is 60%, before applyingbudget extensions.We show ten of the extended jobs in Figure 10. We see thatthe predicted execution times are close to the actual budgetspent. The predicted times are higher than the spent budgets byjust 0.88% on average for this experiment, when the predictedtimes are more than the actually spent budgets. In Figure 10,Job ID 6, 8 and 10 show lower predicted times than the actualspent budgets. For these jobs, the system is switched to HI-mode because the extended LO-mode is not enough for a taskto complete its job. In these cases, the predicted times aresmaller than the spent budgets by 0.49%.This experiment shows that the checkpoint is effectivelybeing used to predict the execution time of a high-criticalitytask in most cases. The budget extensions are a reasonableestimate of the actual task requirements.
F. Overheads
The main overhead of AMC-PAStime over AMC is theonline schedulability test. We first derive an upper boundon this overhead by offline analysis and compare with theexperimental measurements.
1) Offline Upper Bound:
Our offline upper bound is the to-tal number of iterations in solving the response time recurrencerelations during the schedulability test in AMC-PAStime. Wegenerate 500 random tasksets of 20 tasks for different initialLO-mode utilizations. Initial LO-mode utilization ranges from40% to 90%. The utilization of each individual task is gener-ated using the UUnifast algorithm, and each period is takenfrom 10 to 1000 simulated time units, as done in previouswork [10], [24]. As our experimental taskset has a criticalityfactor (CF = C ( HI ) C ( LO ) ) of ~1.8, we test with a CF of . aswell.Among the schedulable tasks with AMC scheduling, weincrease the demand in LO-mode budget of the highest prioritytask. Then, we calculate the total number of iterations neededto determine whether an extension of the budget can beapproved by an offline version of Algorithm 1. Here, oneiteration is a single update to the response time in any oneof the recurrence equations (in Equations 4 and 5) used totest for schedulability.In Figure 11, we show the maximum number of iterationstaken to decide the schedulability of a taskset against a demandof 10 to 80% extra budget in LO-mode by the highest prioritytask. Each point in the figure represents the maximum itera-tions across the 500 tasksets to either approve or disapproveof schedulability.The figure shows the case with 60% initial total LO-modeutilization (before applying budget extensions). The extrademand shown on the x-axis cannot go beyond 80% as theCF is . . As expected, disapproval takes fewer iterations thanapproval of a taskset.We have carried out offline analyses with other initial totalLO-mode utilizations, as stated above. We have observed thenumber of iterations to be as high as . Therefore, we set120 as the highest number of allowed iterations for the onlineschedulability test. When the number of iterations exceed 120at runtime, we disapprove a LO-mode budget extension. Thisstrategy maintains a safe and known upper bound on the onlineoverhead of AMC-PAStime.10 ) Microbenchmarks: Each iteration of a response time cal-culation has a worst-case time of 1 µ s, for our implementationof Algorithm 1 in LITMUS RT . Therefore, we bound the worst-case delay for the online schedulability test in LITMUS RT at120 µ s for our test cases.Additionally, the worst-case user-space execution time forour EXTEND_BUDGET macro is 10 µ s. Hence, the maximumtotal overhead of an EXTEND_BUDGET macro call, accountingfor the schedulability test, is 130 µ s. The 130 µ s overhead isfactored into the LO-mode extension inside the LITMUS RT kernel.Figure 12 shows the number of iterations for the onlineschedulability test for a taskset of 20 tasks with 60% initialtotal LO-mode utilization. We see that the offline bound of 120iterations is much higher than the actually observed number ofiterations. Hence, we never need to abandon the schedulabilitytest because of excessive overheads. In addition, disapprovaltakes less time than approval online, which corroborates ouroffline observation in Figure 11.Figure 13 shows the maximum and average times for aLO-mode budget extension decision by our online versionof Algorithm 1. It demonstrates that the extension approvaldecision, along with the schedulability test, takes more timewith increasing number of tasks. However, the maximumtimes are still significantly lower than the offline upper boundof 130 µ s for 20 tasks. In general, budget extension andschedulability test overheads can be bounded according to thenumber of tasks in the system.VI. R ELATED W ORK
The problem of determining tight worst-case execution time(WCET) bounds for tasks [49] is compounded by timing vari-ations caused by caches, buses and other hardware features.Recently, mixed-criticality systems (MCSs) [8]–[10], [14],[18], [48] have gained popularity as they allow tasks to havemultiple estimates of execution time at different criticality,or assurance, levels. Baruah et al. proposed Adaptive MixedCriticality (AMC) as a fixed-priority scheduling policy formixed-criticality systems [10]. AMC dominates other fixed-priority scheduling schemes, such as Static Mixed-criticalitywith Audsley’s priority assignment and Period Transformationfor random tasksets [10], [24].AMC scheduling affects the QoS of low-criticality tasksby dropping them in HI-mode. Further research work ex-plored adjustments to the task model, including stretchingthe periods [22], [42]–[45], and using reduced budget in HI-mode [7], [8], [36], [39], to provide improved service to thelow-criticality tasks. In this paper, we extend the original AMCtask model with a runtime scheduling policy based on theexecution progress of a high-criticality task. Other task modelsare complementary to PAStime’s scheduling approach.Santy et al. proposed the idea of a task allowance [41].The allowance is statically calculated, and a possible onlineimplementation of the allowance is provided. In our currentwork, we do not compute any allowance offline. Rather, we dynamically decide whether a task is given extra budget in LO-mode based on the observed runtime delay at a checkpoint.PAStime is then able to decide which task’s budget to extendin LO-mode, given the slack in computational resources [18].In addition, we provide a working implementation of PAStime,coupled with AMC, in LITMUS RT .The work by Kritikakou et al. uses run-time monitoringand control in mixed-criticality systems, to increase task par-allelism [27]–[29]. The authors run high- and low-criticalitytasks together and monitor high-criticality tasks at multiple observations points embedded into their control flow graphs.If interference from the low-criticality tasks is too prohibitivefor the high-criticality tasks, low-criticality tasks are stoppedto ensure that the high-criticality tasks meet their deadlines.The authors use static execution time analysis to decidewhether to run the low-criticality tasks after an observationpoint in a high-criticality task. In our work, we dynamicallyadjust LO-mode budgets of the high-criticality tasks when wedetect delays at intermediate checkpoints. We decide aboutthe LO-mode budgets based on the observed progress, insteadof using static offline remaining time as used by the otherwork. In addition, we have implemented an LLVM compilerpass to instrument checkpoints in real-world applications,which have been tested with a PAStime implementation inLITMUS RT . Notwithstanding, Kritikakou et al. provide animportant WCET analysis using CFGs for high-criticalitytasks.Previous ideas of progress-based scheduling were proposedto improve GPU performance [4], [26], fairness among multi-ple threads [20], [21] and to account for instruction cycles [19].Most of these works run a task in an isolated environment andcompare its progress to an online parallel execution with othertasks. Somewhat similar to the motivation behind Jeong et al’swork [26], we also meet the deadlines of high-criticality tasks.However, PAStime uses CFGs to monitor progress rather thanapplication-specific features such as frame processing rates inmultimedia applications as done in the other works.VII. C ONCLUSIONS AND F UTURE W ORK
This paper presents PAStime, a scheduling strategy basedon the execution progress of a task. Progress is measured byobserving the time taken for a program to reach a designatedcheckpoint in its control flow graph (CFG). We integratePAStime in mixed-criticality systems by extending AMCscheduling. PAStime extends the LO-mode budget of a high-criticality task based on its observed progress, given that theextension does not violate the schedulability of any tasks.We carry out a bounded online schedulability test based onoffline response time values. We also provide the responsetime equations for online calculations. Our extension to AMCscheduling, called AMC-PAStime, is shown to improve theQoS of low-criticality tasks.Moreover, we provide an algorithm to detect viable loca-tions for program checkpoints. We modify the LLVM com-piler to automatically instrument checkpoints for use in taskprofiling and runtime execution.11e have implemented both AMC and AMC-PAStime inLITMUS RT and compared their performance. While both meetdeadlines for all high-criticality tasks, AMC-PAStime im-proves the average utilization of low-criticality tasks by 1.5–9times for 2–20 total tasks. For 8 tasks, PAStime increases CPUtime to low-criticality tasks until the system reaches 70% LO-mode utilization, after which it converges with AMC. AMC-PAStime is shown to yield improved performance for low-criticality tasks while reducing the number of mode switches.It also has a bounded overhead for its online schedulabilitytest.In future work, we will explore other uses of progress-awarescheduling in timing-critical systems. We plan to extend theLinux kernel SCHED_DEADLINE policy [31], [32], [35] tosupport progress-aware scheduling. The aim is to improve theQoS of non-time-critical tasks in Linux while timing critical
SCHED_DEADLINE tasks meet their deadlines.We believe that PAStime is applicable to timing-sensitivecloud computing applications, where it is possible to adjustpower (e.g., via Dynamic Voltage Frequency Scaling) basedon progress. Application of PAStime to domains outside real-time computing will also be considered in future work.R
Proceedings of the IEEE International Paral-lel and Distributed Processing Symposium (IPDPS) , 2015, pp. 979–988.[5] N. C. Audsley, “On Priority Assignment in Fixed Priority Scheduling,”
Information Processing Letters , vol. 79, no. 1, pp. 39–44, 2001.[6] S. Baruah and A. Burns, “Fixed-priority Scheduling of Dual-criticalitySystems,” in
Proceedings of the 21st International conference on Real-Time Networks and Systems . ACM, 2013, pp. 173–181.[7] S. Baruah, A. Burns, and Z. Guo, “Scheduling Mixed-criticality Sys-tems to Guarantee Some Service under All Non-erroneous Behaviors,”in .IEEE, 2016, pp. 131–138.[8] S. Baruah, H. Li, and L. Stougie, “Towards the Design of CertifiableMixed-criticality Systems,” in
Proceedings of the 16th IEEE Real-Timeand Embedded Technology and Applications Symposium (RTAS) , 2010,pp. 13–22.[9] S. Baruah and S. Vestal, “Schedulability Analysis of Sporadic Tasks withMultiple Criticality Specifications,” in
Proceedings of the EuromicroConference on Real-Time Systems (ECRTS) , 2008, pp. 147–155.[10] S. K. Baruah, A. Burns, and R. I. Davis, “Response-time Analysis forMixed Criticality Systems,” in
Proceedings of the 32nd IEEE Real-TimeSystems Symposium (RTSS) , 2011, pp. 34–43.[11] E. Bini and G. C. Buttazzo, “Measuring the Performance of Schedula-bility Tests,”
Real-Time Systems , vol. 30, no. 1-2, pp. 129–154, 2005.[12] B. Brandenburg and J. H. Anderson, “Scheduling and Locking inMultiprocessor Real-time Operating Systems,” Ph.D. dissertation, PhDthesis, The University of North Carolina at Chapel Hill, 2011.[13] A. Burns and S. Baruah, “Towards a more practical model for mixed crit-icality systems,” in
Workshop on Mixed-Criticality Systems (colocatedwith RTSS) , 2013.[14] A. Burns and R. I. Davis, “A Survey of Research into Mixed CriticalitySystems,”
ACM Comput. Surv. , vol. 50, no. 6, pp. 82:1–82:37, Nov.2017. [Online]. Available: http://doi.acm.org/10.1145/3131347[15] K. Burr and W. Young, “Combinatorial Test Techniques: Table-basedAutomation, Test Generation and Code Coverage,” in
Proceedings ofthe International Conference on Software Testing Analysis & Review ,1998. [16] J. M. Calandrino, H. Leontyev, A. Block, U. C. Devi, and J. H.Anderson, “LITMUS RT : A Testbed for Empirically Comparing Real-time Multiprocessor Schedulers,” in . IEEE, 2006, pp. 111–126.[17] R. I. Davis, A. Zabos, and A. Burns, “Efficient Exact SchedulabilityTests for Fixed Priority Real-time Systems,” IEEE Transactions onComputers , vol. 57, no. 9, pp. 1261–1276, 2008.[18] D. De Niz, K. Lakshmanan, and R. Rajkumar, “On the Scheduling ofMixed-criticality Real-time Task Sets,” in
Proceedings of the 30th IEEEReal-Time Systems Symposium (RTSS) , 2009, pp. 291–300.[19] S. Eyerman and L. Eeckhout, “Per-thread Cycle Accounting in SMTProcessors,”
ACM Sigplan Notices , vol. 44, no. 3, pp. 133–144, 2009.[20] J. Feliu, J. Sahuquillo, S. Petit, and J. Duato, “Addressing Fairness inSMT Multicores with a Progress-aware Scheduler,” in
Proceedings ofthe IEEE International Parallel and Distributed Processing Symposium(IPDPS) , 2015, pp. 187–196.[21] Feliu, Josue and Sahuquillo, Julio and Petit, Salvador and Duato, Jose,“Perf&Fair: A Progress-aware Scheduler to Enhance Performance andFairness in SMT Multicores,”
IEEE Transactions on Computers , vol. 66,no. 5, pp. 905–911, 2017.[22] C. Gill, J. Orr, and S. Harris, “Supporting Graceful Degradation throughElasticity in Mixed-Criticality Federated Scheduling,” in
Proc. 6thWorkshop on Mixed Criticality Systems (WMC), RTSS , 2018, pp. 19–24.[23] Google, “trucov,” https://code.google.com/archive/p/trucov/, 2018.[24] H.-M. Huang, C. Gill, and C. Lu, “Implementation and Evaluationof Mixed-criticality Scheduling Approaches for Sporadic Tasks,”
ACMTransactions on Embedded Computing Systems (TECS) , vol. 13, no. 4s,p. 126, 2014.[25] Intel, “Intel R (cid:13) Proceedings of the 49th annual DesignAutomation Conference . ACM, 2012, pp. 850–855.[27] A. Kritikakou, O. Baldellon, C. Pagetti, C. Rochange, and M. Roy, “Run-time Control to Increase Task Parallelism in Mixed-critical Systems,” in
Proceedings of the 26th Euromicro Conference on Real-Time Systems(ECRTS) , 2014.[28] A. Kritikakou, T. Marty, and M. Roy, “DYNASCORE: DYNAmicSoftware COntroller to increase REsource Utilization in Mixed-criticalSystems,”
ACM Transactions on Design Automation of Electronic Sys-tems (TODAES) , vol. 23, no. 2, 2017.[29] A. Kritikakou, C. Rochange, M. Faugère, C. Pagetti, M. Roy, S. Girbal,and D. G. Pérez, “Distributed Run-time WCET Controller for Concur-rent Critical Tasks in Mixed-critical Systems,” in
Proceedings of the22nd International Conference on Real-Time Networks and Systems .ACM, 2014.[30] C. Lattner and V. Adve, “LLVM: A Compilation Framework for LifelongProgram Analysis & Transformation,” in
Proceedings of the Interna-tional Symposium on Code Generation and Optimization: Feedback-directed and Runtime Optimization . IEEE Computer Society, 2004,p. 75.[31] J. Lelli, G. Lipari, D. Faggioli, and T. Cucinotta, “An Efficient andScalable Implementation of Global EDF in Linux,” in
Proceedings ofthe 7th International Workshop on Operating Systems Platforms forEmbedded Real-Time Applications (OSPERT) , 2011, pp. 6–15.[32] J. Lelli, C. Scordino, L. Abeni, and D. Faggioli, “Deadline Schedulingin the Linux kernel,”
Software: Practice and Experience , vol. 46, no. 6,pp. 821–839, 2016.[33] T.-Y. Lin, M. Maire, S. Belongie, J. Hays, P. Perona, D. Ramanan,P. Dollár, and C. L. Zitnick, “Microsoft COCO: Common Objects inContext,” in
Proceedings of the European Conference on ComputerVision
IEEE Transactions on Computers , vol. 67, no. 7, pp. 975–991, 2018.
37] D. Liu, J. Spasic, N. Guan, G. Chen, S. Liu, T. Stefanov, and W. Yi,“Edf-vd scheduling of mixed-criticality systems with degraded qualityguarantees,” in .IEEE, 2016, pp. 35–46.[38] NA, “Will be made available after publication,” 2019.[39] S. Ramanathan, A. Easwaran, and H. Cho, “Multi-rate Fluid Schedulingof Mixed-criticality Systems on Multiprocessors,”
Real-Time Systems ,vol. 54, no. 2, pp. 247–277, 2018.[40] J. Redmon, “Darknet: Open Source Neural Networks in C,” http://pjreddie.com/darknet/, 2013–2016.[41] F. Santy, L. George, P. Thierry, and J. Goossens, “Relaxing mixed-criticality scheduling strictness for task sets scheduled with fp,” in . IEEE, 2012, pp.155–165.[42] H. Su, P. Deng, D. Zhu, and Q. Zhu, “Fixed-priority Dual-rate Mixed-criticality Systems: Schedulability Analysis and Performance Optimiza-tion,” in . IEEE, 2016,pp. 59–68.[43] H. Su, N. Guan, and D. Zhu, “Service guarantee exploration for mixed-criticality systems,” in . IEEE,2014, pp. 1–10. [44] H. Su and D. Zhu, “An Elastic Mixed-criticality Task Model andits Scheduling Algorithm,” in
Design, Automation & Test in EuropeConference & Exhibition (DATE) . IEEE, 2013, pp. 147–152.[45] H. Su, D. Zhu, and S. Brandt, “An Elastic Mixed-Criticality Task Modeland Early-Release EDF Scheduling Algorithms,”
ACM Transactions onDesign Automation of Electronic Systems (TODAES) , vol. 22, no. 2,p. 28, 2017.[46] M. M. Tikir and J. K. Hollingsworth, “Efficient Instrumentation forCode Coverage Testing,” in
ACM SIGSOFT Software Engineering Notes ,vol. 27, no. 4. ACM, 2002, pp. 86–96.[47] M. Vanga, A. Bastoni, H. Theiling, and B. B. Brandenburg, “SupportingLow-Latency, Low-Criticality Tasks in A Certified Mixed-CriticalityOS,” in
Proceedings of the 25th International Conference on Real-TimeNetworks and Systems . ACM, 2017, pp. 227–236.[48] S. Vestal, “Preemptive Scheduling of Multi-criticality Systems withVarying Degrees of Execution Time Assurance,” in
Proceedings of the28th IEEE Real-Time Systems Symposium (RTSS) , 2007, pp. 239–243.[49] R. Wilhelm, J. Engblom, A. Ermedahl, N. Holsti, S. Thesing, D. Whal-ley, G. Bernat, C. Ferdinand, R. Heckmann, T. Mitra et al. , “The Worst-case Execution-time Problem - Overview of Methods and Survey ofTools,”
ACM Transactions on Embedded Computing Systems , vol. 7,no. 3, p. 36, 2008., vol. 7,no. 3, p. 36, 2008.