Aperiodic Job Handling in Cache-Based Real-TimeSystems

Sankalpanand MotakpalliSouthern Illinois University Carbondale

Email: sankalpanand@siu.edu

Vardhman Pukhraj JainSouthern Illinois University Carbondale

Email: vardhaman.ms13@gmail.com

Harini RamaprasadSouthern Illinois University Carbondale

Email: harinir@siu.edu

Abstract—Providing a-priori temporal guarantees isparamount in real-time systems. Although much of thenormal operation in such a system is modeled using sporadictasks, event-driven behavior is modeled using aperiodic jobs.To ensure an acceptable Quality of Service for aperiodic jobswithout jeopardizing safety of sporadic tasks, aperiodic serverswere introduced. While aperiodic servers periodically reservea quota for the execution of aperiodic jobs, they do not takeinto account, indirect cache-related delays that the execution ofaperiodic jobs could impose on sporadic tasks, thereby makingtheir use in systems with caches unsafe. In this paper, weintroduce the concept of a Cache Delay Server to solve thisproblem for sporadic tasks (and thus, for periodic tasks). Everysporadic task is allocated a delay quota to accommodate thecache-related delay that could potentially be imposed due toaperiodic job execution. An aperiodic job is allowed to executeonly when all active lower-priority sporadic jobs have sufficientdelay quota to accommodate it. We also present a technique tocalculate delay quotas for sporadic tasks within a given task set.Simulation results demonstrate that the use of a Cache DelayServer ensures safety of sporadic task execution in systemsusing caches while providing reasonable average-case responsetimes to aperiodic jobs.

I. INTRODUCTION AND MOTIVATION

Real-time systems are those in which tasks must satisfytemporal constraints in addition to logical constraints. In orderto guarantee that each task meets its temporal requirements,a schedulability analysis is performed. Schedulability analysisrequires a-priori knowledge of the worst-case execution times(WCETs) of all tasks. The calculation of WCET for tasksis complicated by the use of modern architectural featuressuch as caches. Several researchers have proposed techniquesto characterize cache behavior and thereby calculate realisticWCET estimates for a single task [1], [2], [3], [4], [5], [6], [7],[8], [9] and cache-related preemption delay (CRPD) of tasks inthe context of multi-task systems [10], [11], [12], [13], [14],[15], [16]. Calculation of safe and tight estimates of CRPDallows calculation of safe and tight response time estimates incache-base multi-task systems.

Much of the normal operation of real-time systems ismodeled using hard-deadline tasks that are periodic or sporadicin nature, i.e., it is assumed that either the exact inter-arrivaltime between jobs of a task is known (periodic task) or theminimum inter-arrival time between jobs is known (sporadictask). However, event-driven behavior is typically modeledusing aperiodic jobs. In contrast to periodic and sporadic tasksthat have hard (strict) deadlines, aperiodic jobs have soft or

no deadlines. While such aperiodic events must be suitablyhandled to achieve reasonable average response times, theymust not be allowed to jeopardize the safety of existing hard-deadline tasks in the system.

The simplest way of handling aperiodic jobs is to executethem only when there is no active hard-deadline job in thesystem. However, such handling severely degrades the averageresponse times for aperiodic jobs. In order to improve theQuality-of-Service (QoS) of aperiodic jobs, the concept of anaperiodic server was proposed by Sprunt et al. [17]. The ideaof an aperiodic server is to reserve an amount of executiontime, at periodic intervals, for the servicing of aperiodic jobs.The aperiodic server itself executes as a hard-deadline taskwith a constant inter-arrival time and is considered as such forthe purposes of system schedulability analysis. The underlyingassumption is that, as long as the execution of aperiodic jobsis restricted to the reserved execution quota, it does not affectthe predictability and timeliness of hard-deadline tasks.

Existing work on aperiodic servers [17] does not con-sider indirect interferences among aperiodic and hard-deadlinetasks due to shared architectural resources such as caches.Specifically, although the execution budget/quota given toaperiodic jobs is considered during schedulability analysis,indirect cache-related delay that the execution of aperiodicjobs may impose on hard-deadline tasks is not considered.This cache-related delay could potentially cause sporadic tasksto miss their deadlines, thereby jeopardizing the safety ofthe system. Consider an aperiodic server with an executionquota of 20 and a period of 100. Since the execution quotais accounted for during schedulability analysis, direct delaydue to the execution of an aperiodic job (up to 20 units in aperiod of 100 units) can be tolerated by hard-deadline tasks.However, the indirect cache delay that is imposed on thehard-deadline tasks is unaccounted for and can cause deadlinemisses. Simply increasing the execution quota of an aperiodicserver does not guarantee safety.

The maximum CRPD that a single preemption by an ape-riodic job can impose on a given hard-deadline task can becalculated using existing CRPD estimation techniques. How-ever, it is not possible to bound the number of preemptions byaperiodic jobs a-priori since their arrival times are unknown,preventing static estimation of total CRPD due to aperiodicjob execution. This calls for dynamic approaches to handleindirect cache delays. In this paper, we propose an addition,

which we call Cache Delay Server (CDS), to the concept of anaperiodic server. While maintaining reasonable response timesfor aperiodic jobs, a CDS ensures that this does not come atthe cost of deadline misses for hard-deadline tasks.

II. BACKGROUND AND RELATED WORK

A. Aperiodic Job Scheduling

Aperiodic jobs have unknown arrival times and have softor no deadlines and are typically serviced in a first-in-first-out manner. To obtain acceptable QoS for aperiodic jobs, theymust be executed as soon as possible, but they must not beallowed to jeopardize the deadlines of hard-deadline tasks.Several techniques have been proposed to schedule aperiodicjobs in conjunction with hard-deadline tasks [17], [18], [19].However, none of these techniques specifically account forpossible indirect effects such as cache interferences betweensoft- and non-real-time jobs and hard-real-time jobs. In thispaper, we enhance one approach, namely aperiodic servers,to account for such cache interferences. A brief discussion ofsome aperiodic servers is provided below.

Background Servers The aperiodic server is given thelowest priority within the system so that tasks with harddeadlines are unaffected by aperiodic job execution. The maindisadvantage of this server is that the average response timesfor aperiodic jobs are unacceptably high.

Polling Servers Here, the server itself acts as a periodic taskwith a given priority, a fixed execution quota and a deadlineequal to its period. At the beginning of each period, the serverexecutes jobs from the aperiodic job queue as long as itsexecution quota is not exceeded. If there is no more quota toexecute more jobs, they are carried forward to the next period.If there is any quota left over, it is discarded. The advantageover background servers is that polling servers are given apriority other than the lowest, thereby improving responsetimes of aperiodic jobs. However, these response times arenot predictable on an average since aperiodic jobs that arereleased after the execution of the server are forced to waituntil the next period.

Bandwidth Preserving Servers Similar to the pollingserver, bandwidth preserving servers execute as periodic taskswith hard deadlines. However, in contrast to polling servers,they preserve their execution quota to service aperiodic jobs asthey arrive instead of only at the beginning of the server period.Several bandwidth preserving servers have been proposed withdifferent techniques to preserve bandwidth [20].

In the remainder of this paper, we assume that a bandwidthpreserving server is in use.

B. Cache-Related Preemption Delay (CRPD)

Architectural features such as caches dramatically improveaverage-case performance, but complicate prediction of worst-case behavior. Prediction of cache behavior for a single taskwithout considering inter-task interference has been the focusof much research [1], [2], [3], [4], [5], [6], [7], [8], [9].However, most real-time systems consist of multiple tasks that

operate in prioritized, partially or fully preemptive environ-ments.

In preemptive real-time systems, schedulability analysis is achallenge due to the complexity of calculating WCET boundsfor a task in the presence of caches. If a higher-prioritytask is activated when a lower-priority task is executing,the lower-priority task is preempted and the higher-prioritytask is scheduled. In this scenario, due to overlaps in thecache footprints of the preempted and the preempting tasks,additional cache misses or reloads may be necessary when thepreempted task resumes its execution. The delay due to suchreloads is referred to as the cache-related preemption delay(CRPD). The CRPD constitutes a large part of the context-switch cost.

Several analytical techniques have been proposed to calcu-late the CRPD of tasks [10], [11], [12], [13], [14], [15], [16].The basic idea is to find the number of possible preemptionsfor a given task and calculate the longest delay associatedwith each preemption. The techniques vary in their approachand/or their context of application (instruction caches vs.data caches). Recently, Marinho and Petters [21] proposed atechnique for adaptive, runtime CRPD management using atechnique similar to slack passing among jobs.

In this paper, we employ a technique proposed by Staschulatet al. to calculate the CRPD of tasks [11]. For calculationof WCET, we employ a static timing analysis framework co-developed by Ramaprasad et al. [14]. For any given task, thestatic timing analysis framework is capable of calculating 1)the WCET of that task when it executes in a stand-alonemanner, i.e., with no interference from other tasks, 2) theWCET of a task including the total CRPD experienced bya task when it executes as part of a prioritized task set and3) the maximum CRPD that a task may experience duringany one preemption by a given set of higher-priority tasks.In addition, the framework can also calculate the WCET of atask when it is not allowed to use the cache at all.

Note that our proposed algorithm is not dependent on anyparticular technique for calculating CRPD/WCET and theuse of above-mentioned CRPD technique and timing analysisframework is a matter of choice.

III. ASSUMPTIONS AND TASK MODEL

The work presented in this paper supports fully preemptiveexecution of sporadic hard-real-time tasks with known mini-mum inter-arrival times (hereafter referred to as periods) andconstrained deadlines (i.e. relative deadlines of tasks are lessthan or equal to their periods) in the presence of aperiodicjobs that have soft or no deadlines. Bandwidth preservingaperiodic servers, executed as hard-deadline tasks with pre-assigned replenishment periods and execution quotas, are usedto service aperiodic job requests. We assume a uniprocessorplatform and the use of a static-priority scheduling algorithmfor all hard-deadline tasks, including aperiodic servers. Thealgorithm presented in this paper can be applied to bothinstruction and data caches, as long as the underlying CRPDcalculation technique can support this.

An aperiodic job is represented as AJi where i is a uniqueidentifier assigned to each aperiodic job upon its arrival.Every aperiodic job has two characteristics, represented bythe tuple (ri, ei). ri represents the arrival time and ei, theactual execution time of the aperiodic job, both of which areunknown a-priori.

A sporadic task set consists of n tasks, with IDs 0 to n−1, indecreasing order of priority. A sporadic task is denoted as τi,where i is a unique identifier. The jth instance of τi is denotedas job Ji,j . Alternatively, it may be denoted as τi - Jj . Thebasic characteristics of hard-deadline tasks, represented by thetuple (Pi, SACi, Di), are described below.1. Pi represents the minimum inter-arrival time (referred to asperiod in the remainder of this paper) of task τi.2. SACi represents the worst-case execution time (WCET) oftask τi in isolation, i.e., assuming it is the only task executingin the system.3. Di represents the relative deadline of task τi.A Cache Delay Server is a special sporadic task that is denotedas CSi instead of τi and whose inter-arrival time is alwaysequal to its minimum inter-arrival time (i.e., its execution quotais replenished every Pi units of time).

In the context of a task set, a sporadic task τi has additionalderived characteristics, represented by the tuple (Ci, Qi, Δi,j ),as described below.1. Ci represents the worst-case execution time (WCET) oftask τi, including CRPD due to other sporadic (hard-deadline)tasks.2. Qi represents the delay quota that task τi can endure withoutaffecting task set schedulability.3. Δi,j represents the maximum CRPD that a sporadic task oran aperiodic job with ID j (i.e., τj or AJj ) can impose on atask τi.The actual execution time of a given job Ji,j , known only atrun time, is represented as ai,j . The remaining delay quota ofa particular job j of task τi at any given time is representedas Qi,j . The initial value of Qi,j is equal to Qi.

IV. CACHE DELAY SERVER (CDS)

We introduce the concept of a Cache Delay Server thatmay be used in conjunction with a bandwidth preservingaperiodic server. The purpose of a CDS is to ensure that theexecution of aperiodic jobs does not jeopardize hard-real-timejobs in the system due to cache interferences. For the sake ofsimplicity, throughout the remainder of this paper, we will usethe terms “Cache Delay Server” or “CDS” or simply “server”to represent a bandwidth preserving aperiodic server that hasbeen enhanced with the cache delay server algorithm.

As mentioned in Section III, we assume that the WCET(Ci) of a sporadic task τi already includes worst-case cache-related preemption delay incurred due to interference fromother sporadic tasks. In order to account for cache delay dueto interference from aperiodic jobs, every sporadic task τi inthe system is assigned what we call a delay quota, representedas Qi. This delay quota is assigned statically and is taken into

account during schedulability analysis simply by adding thedelay quota of a sporadic task to its WCET.

Note that, while it may seem easier to add “delay quotas”directly to the execution quota of the CDS itself, distributingdelay quotas to each lower-priority sporadic task insteadpotentially improves the average response times of aperiodicjobs. Consider an aperiodic job AJj with execution time ejthat imposes a CRPD of Δi,j , respectively on each lower-priority sporadic task τi. Being able to accommodate ej andthe sum of Δi,j for all lower-priority sporadic tasks within theexecution quota and deadline of the aperiodic server is muchless likely than being able to accomodate just ej within theserver and individual Δi,j values within the respective lower-priority task WCETs and deadlines.

Algorithm 1 shows the working of the CDS within a real-time scheduling framework. This algorithm is invoked at everyscheduling point. Specifically, it is invoked when a new job isactivated and when a job completes its execution. If there areany active jobs, the scheduler identifies the job with highestpriority. If this job belongs to a regular sporadic task, it isscheduled as usual. On the other hand, if a CDS has the highestpriority, waiting aperiodic jobs are scheduled if possible.

The crux of the operation of a CDS is in lines 11 to 33. Awaiting aperiodic job is scheduled for execution if and onlyif every active lower-priority sporadic job that has alreadybegun execution has sufficient delay quota to accommodate it1. Since aperiodic jobs are serviced only when the CDS hasthe highest priority in the system, there cannot be any higher-priority sporadic jobs active in the system.

If there is sufficient delay quota in all sporadic jobs thatmay be affected, their delay quotas are decremented by themaximum CRPD that the aperiodic job to be executed mayimpose, respectively on each sporadic job 2.

The chosen aperiodic job is scheduled. Lines 26 to 28 inAlgorithm 1 show these steps. On the other hand, if anysporadic job has insufficient delay quota, the CDS is temporar-ily deactivated and is reactivated upon that job’s completion.While continuing to allow aperiodic job execution at theassigned server priority whenever possible, the CDS ensuresthat no sporadic job misses its deadline due to aperiodic jobexecution. Since delay quotas of sporadic tasks are staticallyassigned and added to their WCET for schedulability analysispurposes, our algorithm ensures safety as long as it is usedin conjunction with safe CRPD/WCET estimation techniques.Our algorithm also supports the use of multiple aperiodicservers with different priorities, each servicing a separateaperiodic job queue.

All real-time scheduling algorithms impose a scheduling

1Due to the complexity and, hence, high degree of pessimism involved ininter-job CRPD analysis, static timing analysis techniques typically assumean empty cache at the beginning of each job. This means that active jobs thathave not yet started execution cannot experience CRPD. However, if a CRPDtechnique is capable of performing inter-job analysis, our algorithm may beeasily modified to consider all active lower-priority jobs.

2In situations where the code for an aperiodic job is not known a-priori, ouralgorithm may be modified to use the maximum CRPD that a given sporadicjob can incur due to preemption.

Algorithm 1 Cache Delay Server Algorithm1: CS ids, lpi, update: list of ids2: pick new task, quota: boolean values3: i, j, l, lowest: ids

4: CS ids← getCacheDelayServerIDs()5: pick new task ← true6: while (pick new task = true) do7: if (active task exists in system) then8: i← identifyHighestPriorityTask()9: if (i ∈ CS ids) then

10: if (aperiodic job in CDS queue) then11: j ← id of first aperiodic job in queue12: quota← true13: lpi ← getActiveLowerPriorityJobIDs(i)14: lowest← 015: update← ∅16: for (∀l ∈ lpi in decreasing priority order) do17: if job of PTl has started then18: if (Ql < Δl,j) then19: quota← false20: lowest← l

21: update← update ∪ l

22: end if23: end if24: end for25: if (quota = true) then26: updateDelayQuotas(update)27: scheduleAperiodicJob(j)28: pick new task← false29: else30: deactivateCDS()31: setUpCDSReactivateNotification(lowest)32: pick new task← true33: end if34: else35: deactivateCDS()36: {CDS reactivated on aperiodic job arrival}

37: pick new task← true38: end if39: else40: scheduleSporadicTask(i)41: pick new task← false42: end if43: else44: pick new task ← false45: end if46: end while

overhead on a sporadic task set and this is typically accountedfor by adding context switch costs to the WCETs of eachsporadic task. In addition to this regular overhead, our CDSalgorithm adds the overhead of checking for delay quotaavailability every time an aperiodic job needs to be scheduled.The complexity of this check is proportional to the numberof active sporadic jobs with priority lower than the CDS.We currently assume that the deadline of every sporadic taskis less than or equal to its period. As such, there may beonly one active job of each task at any given time. Since thepriority of the CDS is known statically, the complexity of ouralgorithm can be tightly bounded. This overhead may then beadded to the execution times of aperiodic jobs, thus indirectlyaccounting for it within the execution quota of the aperiodicserver.

V. DELAY QUOTA

There are four factors that determine the average responsetimes of aperiodic jobs in the presence of a CDS, namely1) the priority assigned to the CDS; 2) the execution quotaof the CDS; 3) the delay quota assigned to sporadic taskswith a priority lower than that of the CDS and 4) the arrivalpattern of aperiodic jobs. In this section, we present a delayquota assignment technique that strives to maximize the delayquotas assigned to sporadic tasks while ensuring task setschedulability.

A. Delay Quota Assignment

Sporadic tasks are sorted in decreasing order of priority,assigned using the Deadline Monotonic (DM) policy. Accord-ing to the CDS algorithm, an aperiodic job cannot execute atthe priority of its aperiodic server (non-background execution)unless all lower-priority sporadic tasks have sufficient delayquota to accommodate it. A greedy approach that starts withthe highest-priority sporadic task and moves towards lower-priority sporadic tasks, assigning maximum possible delayquotas at each step, is not useful since lower-priority sporadictasks may end up being left with no possibility of a delayquota due to schedulability reasons. Our goal is to employ asystem-wide approach that strives to maximize the probabilityof all sporadic tasks that need a delay quota assignmenthaving a non-zero delay quota, when possible, while ensuringschedulability.

We formulate and solve an Integer Linear Program (ILP)for delay quota assignment. Our objective is to maximise theoverall delay quota considering all tasks, represented by theset TDQ, that need delay quotas — note that sporadic taskswith a priority higher than the highest-priority CDS do notneed a quota. Equation 1 shows our objective function thatmaximizes delay quotas.

∑

i∈TDQ

Qi (1)

We now develop constraints to be used for our ILP. We first de-termine the slack time for every hard-deadline task (includingCDSs) that has priority lower than that of the highest-priority

CDS within an interval of time equal to its period. Equation2 shows the calculation performed ∀i ∈ HCS + 1..n− 1,

Si = min(Pi, Di)−

i∑

k=0

�min (Pi, Di)

Pk

� � Ck (2)

where n is the number of tasks in the task set, Si is the slacktime for task τi and HCS is the ID of the highest-priorityCDS.

Lemma 1: Equation 2 calculates a safe estimate of the slacktime of a task τi in the context of a sporadic task set τcq

comprised of n independent, constrained-deadline sporadictasks where every task τi is characterized by (Pi, Di, Ci).

Proof: The summation in Equation 2 gives an upperbound on the time occupied by the execution of tasks withpriority higher than τi and τi itself since it assumes the worst-case number of releases of higher-priority tasks within theinterval min(Pi, Di). The remaining time in this interval ishence slack time for the task τi, implying that τi can toleratean increase in response time of upto Si time units withoutbecoming unschedulable.Response time analysis may be used instead of Equation 2to calculate more accurate, potentially larger values for Si.However, although Si is the slack time available for task τiwithin its own deadline, a delay quota of Si may not be allow-able since delay quota assignment increases a task’s effectiveWCET and, hence, the response times of lower-priority tasks,thus affecting task set schedulability. Hence, there is no gainachieved by using a computationally much more complex,iterative approach such as response time analysis, leading usto prefer Equation 2.

The maximum delay quota of task τi, namely Qmaxi , must

be a value that can be accommodated by tasks with lowerpriority than τi. Specifically, every task with lower prioritythan τi must be able to accommodate the cumulative delayquota of the worst-case number of jobs of τi released duringits period within its relative deadline. Equations 3 and 4 showthe calculation of Qmax

i and the constraint that it introduceson Qi, respectively, ∀i ∈ HCS + 1..n− 1.

Qmaxi = min[Si,

n−1

mink=i+1

(Sk

�min(Pk,Dk)Pi

�)] (3)

0 ≤ Qi ≤ Qmaxi (4)

i∑

k=HCS+1

�min (Pi, Di)

Pk

� � Qk ≤ Qmaxi (5)

Qmaxi of a given task τi is calculated such that assignment

of a quota of Qmaxi to task τi does not by itself violate the

schedulability of lower-priority tasks. However, the effect ofmultiple tasks that are each assigned their individual maximumallowable quotas can violate schedulability. Hence, Qmax

i isin reality a limit on the sum of the delay quotas of all jobsof priority equal to or higher than τi that execute within oneperiod of task τi. Equation 5 establishes a safe limit on thiscumulative delay quota by assuming the worst-case number

of releases of jobs with priority equal to or higher than taskτi within one period of task τi.

In order to improve the probability of obtaining non-zerodelay quotas, whenever possible, we introduce the optionalconstraint shown in Equation 6 for all sporadic tasks that needa quota.

Qi∑j∈HCS(i)�

min (Pi,Di)Pj

� � Cj

=Qk∑

j∈HCS(k)�min (Pk,Dk)

Pj� � Cj

∀i, k ∈ TDQ

(6)

Here, HCS(i) is the set of cache delay servers with a higherpriority than task τi. The basic idea behind this equation isto divide available quota among tasks in proportion to thecumulative execution quota of all aperiodic server instancesaffecting each task within its period. Note that this constraintis not required for schedulability. Hence, if the addition of thisoptional constraint leads to no feasible assignment of delayquotas for a given task set, we remove this constraint andsolve the ILP with only the schedulability constraints shownin Equations 2-5.

Finally, although aperiodic server characteristics must beconsidered during delay quota assignment for schedulabilityreasons, the servers themselves need no delay quota. Weintroduce explicit constraints for every aperiodic server toaccommodate this.

Theorem 2: A sporadic task set τcq comprised of n inde-pendent, constrained-deadline sporadic tasks where every taskτi is characterized by (Pi, Di, Ci + Qi) and Qi satisfiesthe constraints shown in Equations 2-5 is schedulable on auniprocessor system using Deadline Monotonic (DM) priorityassignment if and only if the sporadic task set τc where everytask τi is characterized by (Pi, Di, Ci) is schedulable.

Proof: Part 1: If task set τc where every task τi has aWCET of Ci is not schedulable under DM, then increasing theWCET of any task in this set makes it remain unschedulableunder DM. From Equation 4, ∀i, Qi ≥ 0. This implies thatsporadic task set τcq where every task τi has a WCETof Ci + Qi cannot be schedulable. This shows that τcq isschedulable only if τc is schedulable. Part 2: Let us assumethat sporadic task set τc is schedulable, but that sporadictask set τcq is not schedulable. Since τc is schedulable,the assignment of delay quota to tasks is the reason forschedulability violation in τcq . Let us assume that τi is thefirst task to miss its deadline. From Lemma 1, this implies that∑i

j=HCS+1�min (Pi,Di)

Pj � Qj > Si. However, by Equation

5,∑i

j=HCS+1�min (Pi,Di)

Pj � Qj ≤ Qmax

i and by Equation3, Qmax

i ≤ Si. This results in a contradiction and henceproves that, under the constraints of Equations 2-5, if τc isschedulable, then τcq is schedulable.

VI. ILLUSTRATIVE EXAMPLE

We now illustrate our approach for delay quota calculationand our CDS algorithm with the task set whose characteristicsare shown in Table I. The WCET (Ci, shown in the third

column) of each task includes CRPD due to interference fromother sporadic jobs and priorities (shown in the last column)are assigned using the Deadline Monotonic policy. The fifthcolumn shows the delay quotas that are assigned to tasks usingthe ILP described in Section V-A, calculated as shown next.All times are shown in clock cycles.

Task Period WCET Relative Delay Priority(Pi) (Ci) Deadline (Di) Quota (Qi)

τ0 100 10 100 - 1CS1 300 60 100 - 2τ2 150 40 150 18 3τ3 275 50 275 18 4

TABLE ICHARACTERISTICS - TASK SET 1

A. Delay Quota AssignmentUsing Equation 2, we calculate the slack available for tasks

τ2 and τ3 as shown in Equations 7 and 8, respectively.

S2 = 150− �150

100� � 10− �

150

300� � 60− �

150

150� � 40

⇒ S2 = 30(7)

S3 = 275− �275

100� � 10− �

275

300� � 60− �

275

150� � 40− �

275

275� � 50

⇒ S3 = 55

(8)

From Equations 3 and 4, we obtain constraints shown inEquations 9 and 10.

Qmax2 = min[30,min(

55

� 275150�)]

⇒ Qmax2 = min[30,min(27.5)]

⇒ 0 ≤ Q2 ≤ 27.5

(9)

Qmax3 = min[55]

⇒ 0 ≤ Q3 ≤ 55(10)

From Equation 5, we obtain the constraints shown in Equations11 and 12.

�150

150� � Q2 ≤ 27.5

⇒ Q2 ≤ 27.5(11)

�275

150� � Q2 + �

275

275� � Q3 ≤ 55

⇒ 2Q2 +Q3 ≤ 55(12)

Since both τ2 and τ3 are affected by the same number ofinstances of server CS1, the quota is divided equally amongthem in accordance with Equation 6, resulting in the optionalconstraint shown in Equation 13.

Q2

� 150300� � 60

=Q3

� 275300� � 60

⇒Q2

60=

Q3

60⇒ Q2 = Q3

(13)

Finally, from Equation 1, the maximization function for theILP solver is Q2 +Q3. Upon solving Equations 9, 10, 11, 12and 13 with an ILP solver, we get Q2 = 18, Q3 = 18.

B. CDS Algorithm

For the illustration of our CDS algorithm with the task setshown in Table I, we use the sample set of aperiodic jobswhose characteristics are shown in Table II. The fourth andfifth columns of Table II show the maximum CRPD that theaperiodic jobs can impose on lower-priority sporadic tasks τ2and τ3, respectively. It is to be noted that, since τ0 has apriority higher than the CDS CS1, aperiodic jobs that executeat the priority of the CS1 cannot impose CRPD on jobs of τ0.In our current experiments, we assume that aperiodic jobs haveno deadlines and, therefore, are to be executed in a best-effortmanner.

Job Release Time Exec. Time (ei) τ2 Delay τ3 DelayAJ0 60 15 14 10AJ1 90 15 8 10AJ2 125 13 8 7AJ3 150 17 10 13AJ4 170 15 12 8AJ5 55 10 8 5AJ6 20 10 6 6AJ7 30 10 7 8AJ8 45 12 10 9

TABLE IIAPERIODIC JOB CHARACTERISTICS.

Figure 1(a) shows the schedule obtained for the task setshown in Table I and the aperiodic jobs shown in Table II.The x-axis denotes time in number of cycles. Sporadic taskreleases are shown using upward arrows and aperiodic jobarrivals are shown using downward arrows. In this example,we assume that all sporadic jobs execute up to their worst-caseexecution time. Furthermore, when an aperiodic job executes,we assume that maximum amount of delay that the aperiodicjob can impose on lower-priority sporadic jobs gets addedto their execution times. We now describe a subset of thescheduling decisions made in this example, with specific focuson decisions involving aperiodic jobs.

• τ0 completes its first job τ0-J1 at time 10 and τ2-J1 isscheduled.

• At time 20, aperiodic job AJ6 arrives, thereby activatingthe server CS1. τ2 and τ3 are identified as lower-prioritytasks with active jobs. However, only τ2-J1 has startedexecuting. Its delay quota Q2,1 is checked and found tobe sufficient to accommodate AJ6. Hence, the schedulerschedules AJ6. The delay quota, Q2,1, is updated toQ2,1 −Δ2,1 = 18− 6 = 12.

• At time 30, AJ7 arrives. τ2 still has sufficient quota andthus AJ7 is scheduled, leaving Q2,1 = 12− 7 = 5.

• At time 45 AJ8 arrives. Now, τ2 does not have sufficientquota to accommodate AJ8. Hence, the CDS CS1 isdeactivated. A notification request is set up to reactivateCS1 upon completion of τ2’s current job. τ2 is thenscheduled and completes its execution at 82, upon whichCS1 is reactivated.

J1

6050403020100 70 80 90 100 110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 260 270 280 290 300

J1CS1AJ6

AJ6

CS1AJ7

AJ7

J1CS1AJ8

AJ8

J2 J1 J2 J1J2 J3

AJ5 AJ0 AJ1 AJ2 AJ3 AJ4

J2

τ0

τ2

τ3

CS1

τ2 τ2

τ0

τ0 τ3

τ2

τ2

τ0

τ0τ3 τ3

τ3

τ0

τ2

CS1

AJ5

(a) With CDS

J1

CS1

6050403020100 70 80 90 100 110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 260 270 280 290 300

J1CS1AJ6

AJ6

CS1AJ7

AJ7 AJ8

J2 J1J2 J3

AJ5 AJ0 AJ1 AJ2 AJ3 AJ4

J1

CS1AJ8

CS1AJ5

CS1AJ0 J1J1 J1 J1 J2

MISSESDEADLINE

J2

τ3

τ0

τ2

τ2 τ2 τ2 τ0

τ0

τ2

τ2 τ2

τ2 τ3 τ0

τ0

τ3 τ3

τ3

τ0

τ2

τ2

(b) Without CDS

Fig. 1. Schedules obtained with and without Cache Delay Server.

• At time 82 CS1 schedules AJ8 since τ3 has not yetstarted executing and, therefore, cannot be affected. OnceAJ8 finishes, AJ5 is scheduled.

• At time 100, the deadline of CS1 is reached. Hence, CS1

is deactivated. At the same time, τ0-J2 arrives and isscheduled. Execution now proceeds in the usual mannerfor the active sporadic jobs in the system until time 300,when CS1 is re-activated.

In order to demonstrate the importance of using a CDS in asystem using an aperiodic server to schedule aperiodic jobs, wenow present the schedule obtained for the example discussedabove when a CDS is not used, shown in Figure 1(b). Thescheduling decisions up to time 45 are the same as before, sowe only discuss the scheduling decisions after that point.

• At time 45, AJ8 arrives, thus activating CS1. Since thereis no CDS algorithm in place and CS1 has executionquota remaining, AJ8 is scheduled, followed by AJ5 andAJ0.

• At time 82, CS1 is deactivated due to the lack ofaperiodic jobs in the queue and τ2-J1 resumes execution.

• At time 90, AJ1 arrives and is scheduled since CS1 stillhas sufficient execution quota.

• At time 93, CS1 is deactivated since its execution quotais exhausted and τ2-J1 resumes execution. Execution nowproceeds in the usual manner until time 150, when τ2-J1 misses its deadline due to cache delays caused by theexecution of aperiodic jobs.

For the above example, the response times obtained forsporadic and aperiodic jobs that start executing within the timeinterval 0− 150 with and without using a CDS are shown inTable III. From the above example and discussion, it can beseen that allowing aperiodic jobs to execute simply becausethe aperiodic server has sufficient quota is not safe in systemsusing caches.

We see from Table III that, as long as sporadic task dead-

Job RT With CDS RT Without CDSτ0-J1,J2 10 10CS1-AJ6 10 10CS1-AJ7 10 10CS1-AJ8 50 12CS1-AJ5 260 12CS1-AJ0 270 22CS1-AJ1 535 232τ2-J1 83 Misses Deadlineτ3-J1 200 250

TABLE IIIRESPONSE TIMES WITH AND WITHOUT CDS.

lines are not in danger of being missed, aperiodic jobs havesimilar response times both with and without using a CDS.However, in the situation that an aperiodic job’s executioncould jeopardize the safety of a hard-real-time sporadic job,the CDS delays the execution of the aperiodic job, therebyincreasing its response time.

VII. SIMULATION RESULTS

We have developed an in-house simulator for the proposedCDS algorithm. We now present a subset of our simulationresults with task sets constructed using benchmarks programsfrom the DSPStone benchmark suite [22] and for syntheticallygenerated task sets.

All WCET and CRPD values for benchmark programs arecalculated using a static timing analysis framework developedby Ramaprasad et al. [14]. The algorithm presented in this pa-per does not impose any specific restrictions on the instructionset or memory architecture. For the purposes of simulation,in all cases that use benchmark programs, we use a PortableInstruction Set Architecture (PISA), which is a widely usedgeneric instruction set architecture. The system is assumedto have separated, direct-mapped instruction and data caches,

each with a size of 64KB. Cache hit latency is assumed tobe 1 and the miss latency, 100, for simulations with bothbenchmark programs and synthetic tasks. All times, includingcache latencies, are shown in clock cycles.

Table IV shows the details of sporadic tasks (prefix τ )and aperiodic jobs (prefix AJ) constructed using benchmarksfrom the DSPStone suite. The third column shows stand-aloneWCET values of sporadic tasks/aperiodic jobs with the cacheenabled and the last column shows WCETs of aperiodic jobswhen the cache is disabled.

Task ID Name SACi SACi

with Cache with No Cacheτ4 300nrealupdates 143278 −τ5 800convolution 149151 −τ6 800fir 196397 −AJ0 convolution 19751 212751AJ1 200convolution 38451 424951AJ2 300convolution 56651 637157AJ3 400convolution 75351 849351AJ4 500convolution 93551 1061551AJ5 600convolution 112251 1273751AJ6 700convolution 130451 1485951AJ7 fir 25697 318197AJ8 500fir 123097 1590597AJ9 lms 43156 639156AJ10 500lms 206156 3177156AJ11 nrealupdates 49678 635178

TABLE IVTASKS FROM THE DSPSTONE BENCHMARK SUITE

Table V shows the details of sporadic task sets constructedusing benchmarks shown in Table IV that have a prefix of τ inthe first column and cache delay servers with given period andexecution quotas. Here, the WCETs of sporadic tasks includeCRPD due to higher priority sporadic tasks, thus making themlarger than the stand-alone-WCETs shown in Table IV.

Task ID Period WCET Relative Delay Priority(Pi) (Ci) Deadline (Di) Quota (Qi)

τ4 1000000 143278 1000000 − 0CS1 1500000 299376 1000000 − 1τ5 2200000 274651 2000000 86566 2CS3 2500000 240016 2500000 − 3τ6 2500000 422397 2500000 86566 4

TABLE VTASK CHARACTERISTICS - TASK SET 4

Tables VI and VII show the details of aperiodic job setsconstructed using benchmarks from the Table IV that have aprefix of AJ in the first column. The third and fourth columnsin these tables show the CRPD that an aperiodic job imposeson lower-priority sporadic tasks. The last column shows themaximum CRPD that aperiodic jobs itself may experience dueto a single preemption in the context of the sporadic task set inwhich it is executed. Whenever an aperiodic job is preemptedby a higher-priority sporadic task, the maximum CRPD that

it may experience due to a single preemption is added to itsremaining execution time. The aperiodic job sets shown inTables VI and VII are used for the servers CS1 and CS3,respectively, of the task set shown in Table V. In order to

Job ID Release Time τ5 Delay τ6 Delay AP DelayAJ0 44900 6500 2505 13000AJ1 14900 13000 4205 26000AJ1 20000 19000 28405 38000AJ3 1887000 25500 53605 51000AJ4 326000 31500 77805 63000AJ5 90000 38000 103005 76000AJ6 842000 44000 127205 88000AJ7 759000 6500 15049 13000

TABLE VIAPERIODIC JOB CHARACTERISTICS FOR SERVER CS1

Job ID Release Time τ6 Delay AP DelayAJ8 326000 31500 63000AJ9 590000 6500 13000AJ10 1102000 31500 63000AJ11 759000 13000 26000

TABLE VIIAPERIODIC JOB CHARACTERISTICS FOR SERVER CS3

demonstrate the shortcoming of a traditional aperiodic serveralgorithm when used in a system with caches and to evaluatethe effectiveness of our CDS in preventing deadline missesfor hard-real-time sporadic jobs, we simulate a set of threedifferent system configurations.1. NoCache: Here, we disable caches during aperiodic jobexecution so that there is no need for a CDS to ensurethat sporadic tasks meet their deadlines. WCET values foraperiodic jobs when they are not allowed to use caches areshown in the last column of Table IV.2. NoCDS-Cache: Here, we allow aperiodic jobs to use thecache. We do not use the cache delay server algorithm, butuse the traditional aperiodic server algorithm instead.3. CDS-Cache: Here, we allow aperiodic jobs to use the cacheand use our CDS algorithm to ensure that sporadic tasks meettheir deadlines.

In order to study the effect of varying aperiodic workloadon the execution of sporadic tasks and to study the responsetimes of aperiodic jobs themselves, we conduct multiple setsof simulations (where each set consists of the configurationsdiscussed above). To vary the effective aperiodic workload, wevary the execution quota of aperiodic servers in the sporadictask sets shown in Table V between 0 and their respectiveWCET values indicated in the tables, in steps of 5% utilization.

We first present response times results for sporadic tasks.Since sporadic task τ4 has a priority higher than all aperiodicservers, we do not present its response time results. Due tospace constraints, we present results only for the sporadic taskτ6. Note that, in all our simulations, we abort any sporadic jobsthat miss their deadlines and proceed with the simulation. All

Fig. 2. Maximum response times for τ6 (relative deadline = 2500000).

simulations are performed for at least one hyperperiod of thetask set under consideration.

The maximum response times observed for jobs of sporadictask τ6 shown in Table V (affected by two CDSs, namely CS1

and CS3) are shown in Figure 2. The x-axis shows the totalaperiodic workload and the y-axis shows maximum responsetime values in clock cycles obtained across all jobs of τ6.If a sporadic job misses its deadline, the maximum responsetime is depicted as being a few cycles more than the relativedeadline of the task. The three lines for each experimentshow the results of configurations NoCache, NoCDS-Cacheand CDS-Cache, as indicated.

In the NoCache case, response times of sporadic jobsimprove in comparison to NoCDS-Cache. This is because,in the NoCache case, sporadic jobs are only affected by theexecution quota of the aperiodic server, but do not suffercache interference from aperiodic jobs. We will demonstratelater that this is not a good option for aperiodic jobs, sincetheir response times degrade. In the CDS-Cache case, sporadicjobs have a higher response time than in the NoCache casesince they are affected by CRPDs imposed by aperiodic jobs.However, we see that all sporadic jobs still successfully meettheir deadlines in the CDS-Cache case3. In the NoCDS-Cachecase, the response times of sporadic jobs increase significantlywith an increase in the aperiodic workload and, in severalcases, jobs of τ6 miss their deadline. This is because, whenthe CDS is not used, although the server has execution quotato accommodate aperiodic jobs, the indirect cache delay thatthese aperiodic jobs impose on lower-priority sporadic jobs isnot accounted for. Hence, the safety of sporadic jobs may beadversely affected.

We now present response time results obtained forthe aperiodic jobs in the above simulations. For everyaperiodic workload, the average response time (ART) for

3In our simulations, no sporadic jobs miss deadlines under the CDS-Cacheconfiguration, including those whose results are not shown in the currentpaper.

Fig. 3. Average aperiodic job response times for Task Set 4.

each aperiodic job is calculated. We present results forfive different configurations for each aperiodic workload.The first three configurations are ones that were describedearlier, namely NoCache, NoCDS-Cache and CDS-Cache.In addition to these, we present response time results foranother two configurations, namely Background-NoCacheand Background-Cache.1. Background-NoCache: In these simulations, aperiodicservers are assigned the lowest priority among all sporadictasks and aperiodic jobs are not allowed to use the cache.2. Background-Cache: In these simulations, aperiodic serversare assigned the lowest priority among all sporadic tasks andaperiodic jobs are allowed to use the cache.

Figure 3 shows the average response times of aperiodic jobsin Tables VI and VII for the sporadic task set shown in TableV. The x-axis in Figure 3 shows the aperiodic workload andthe y-axis, their average response times in clock cycles. Fromthese figures, we see that the average response times obtainedfor aperiodic jobs when they are not allowed to use thecache are unreasonably high when compared to backgroundexecution with cache or prioritized execution with a CDS, inmost cases. Furthermore, although we know that the use ofa CDS deteriorates aperiodic job response times in order tomaintain sporadic job deadlines, we observe from these figuresthat response times obtained in the CDS-Cache case are stillgenerally better than those obtained in the Background case,thus demonstrating the usefulness of the Cache Delay Server.

In order to study the effects of different arrival patternsof aperiodic jobs, we conducted simulations with synthetictask sets. Here, we use the sporadic task set shown in TableI. We performed simulations with each configuration forseveral randomly generated aperiodic job sets. The numberof aperiodic jobs in each simulation is based on the timeduration of the simulated schedule. This duration is dividedinto intervals of size equal to the CDS period and a minimumof ten aperiodic jobs and a maximum of fifteen aperiodic jobs

Fig. 4. Average aperiodic job response times for Task Set 1.

may arrive in any given interval. A base execution time isgenerated for each aperiodic job such that the execution quotaof the CDS is capable of accommodating a minimum of fourand a maximum of eight aperiodic jobs in any given period.For configurations where aperiodic jobs are allowed to usethe cache, we generate their cache hit ratio to be between 60and 100 percent. For the configuration where aperiodic jobsare not allowed to use the cache, we use a 100 percent cachemiss ratio.

Figure 4 shows the average response times for a subsetof the generated aperiodic job sets. The x-axis shows theaperiodic set and the number of aperiodic jobs. The y-axisshows the average response times of aperiodic jobs in eachset. Once again, we observe the same trend as before, thusdemonstrating that our algorithm works for a range of differentarrival patterns. CDS gives a better response time for aperiodicjobs compared to background execution and execution with nocache, without jeoperdizing the safety of the sporadic tasks.

VIII. CONCLUSIONS

This paper presents a Cache Delay Server (CDS) forhandling aperiodic jobs in systems deployed on cache-basedsingle-core architectures, in order to ensure that cache in-terference from aperiodic job execution does not affect thesafety of hard-real-time sporadic tasks. The CDS algorithm isintended for use with a bandwidth-preserving aperiodic serverto ensure a reasonable response time for aperiodic jobs on anaverage while meeting sporadic job deadlines. An importantfactor affecting response times of aperiodic jobs is delay quotaassignments among sporadic tasks. We present a techniquebased on Integer Linear Programming for assignment of delayquotas. Simulation results demonstrate the effectiveness of aCDS is ensuring that hard-real-time sporadic tasks meet theirdeadlines even in the presence aperiodic jobs. Furthermore,they demonstrate that using a CDS still provides better QoSto aperiodic jobs when compared to background executionof aperiodic jobs or a scheme where aperiodic jobs are notallowed to use the cache.

REFERENCES

[1] S.-S. Lim, Y. H. Bae, G. T. Jang, B.-D. Rhee, S. L. Min, C. Y. Park,H. Shin, K. Park, S.-M. Moon, and C. S. Kim, “An accurate worstcase timing analysis for risc processors,” in IEEE Real-Time SystemsSymposium, 1995, pp. 97–108.

[2] S.-K. Kim and S. L. Min, “Efficient worst case timing analysis ofdata caching,” in In IEEE Real-Time Technology and ApplicationsSymposium. IEEE, 1996, pp. 230–240.

[3] Y.-T. S. Li, S. Malik, and A. Wolfe, “Cache modeling for real-timesoftware: beyond direct mapped instruction caches,” Real-Time SystemsSymposium, IEEE International, vol. 0, p. 254, 1996.

[4] R. T. White, F. Mueller, C. Healy, D. Whalley, M. Harmon, andA. Halang, “Timing analysis for data and wrap-around fill caches,” Real-Time Systems, vol. 17, pp. 209–233, 1999.

[5] T. Lundqvist, P. Stenstrom, T. Lundqvist, and P. Stenstrom, “Empir-ical bounds on data caching in high-performance real-time systems,”Chalmers University of Technology, Tech. Rep., 1999.

[6] B. Fraguela, R. Doallo, E. Zapata, B. B. Fraguela, R. Doallo, and E. L.Zapata, “Automatic analytical modeling for the estimation of cachemisses,” in In International Conference on Parallel Architectures andCompilation Techniques, 1999, pp. 221–231.

[7] S. Chatterjee, E. Parker, P. J. Hanlon, and A. R. Lebeck, “Exact analysisof the cache behavior of nested loops,” SIGPLAN Not., vol. 36, no. 5,pp. 286–297, 2001.

[8] S. Ghosh, M. Martonosi, and S. Malik, “Cache miss equations: Acompiler framework for analyzing and tuning memory behavior,” ACMTransactions on Programming Languages and Systems, vol. 21, pp. 703–746, 1999.

[9] H. Ramaprasad and F. Mueller, “Bounding worst-case data cache be-havior by analytically deriving cache reference patterns,” in In IEEEReal-Time Embedded Technology and Applications Symposium, 2005,pp. 148–157.

[10] C.-G. Lee, K. Lee, J. Hahn, Y.-M. Seo, S. L. Min, R. Ha, S. Hong, C. Y.Park, M. Lee, and C. S. Kim, “Bounding cache-related preemption delayfor real-time systems,” IEEE Transactions on Software Engineering, vol.27(9), pp. 805–826, nov 2001.

[11] J. Staschulat, S. Schliecker, and R. Ernst, “Scheduling analysis of real-time systems with precise modeling of cache related preemption delay,”in Euromicro Conference on Real-Time Systems, 2005.

[12] H. Tomiyama and N. D. Dutt, “Program path analysis to bound cache-related preemption delay in preemptive real-time systems,” ACM Inter-national Symposium on Hardware Software Codesign, 2000.

[13] H. S. Negi, T. Mitra, and A. Roychoudhury, “Accurate estimationof cache-related preemption delay,” ACM International Symposium onHardware Software Codesign, Oct. 2003.

[14] H. Ramaprasad and F. Mueller, “Tightening the bounds on feasiblepreemptions,” ACM Transactions on Embedded Computing Systems,vol. 10, pp. 27:1–27:34, January 2011.

[15] J. C. Kleinsorge, H. Falk, and P. Marwedel, “A synergetic approach toaccurate analysis of cache-related preemption delay,” in EMSOFT, 2011,pp. 329–338.

[16] S. Altmeyer, R. Davis, and C. Maiza, “Improved cache related pre-emption delay aware response time analysis for fixed priority pre-emptive systems,” Real-Time Systems, vol. 48, pp. 499–526, 2012.

[17] B. Sprunt, L. Sha, and J. Lehoczky, “Aperiodic task scheduling for hardreal-time systems,” Real-Time Systems, vol. 1, pp. 27–60, 1989.

[18] L. Abeni and G. Buttazzo, “Integrating multimedia applications in hardreal-time systems,” in IEEE Real-Time Systems Symposium, 1998, pp.4–13.

[19] S. A. Brandt, S. Banachowski, C. Lin, and T. Bisson, “Dynamicintegrated scheduling of hard real-time, soft real-time and non real-timeprocesses,” in IEEE Real-Time Systems Symposium, 2003.

[20] J. K. Strosnider, J. P. Lehoczky, and L. Sha, “The deferrable serveralgorithm for enhanced aperiodic responsiveness in hard real-time envi-ronments,” IEEE Trans. Comput., vol. 44, no. 1, pp. 73–91, 1995.

[21] J. Marinho and S. M. Petters, “Runtime crpd management for rate-basedscheduling,” in Workshop on Adaptive Resource Management (WARM2010) during CPSWEEK 2010, Apr. 2010.

[22] V. Zivojnovic, J. Velarde, C. Schlager, and H. Meyr, “Dspstone: A dsp-oriented benchmarking methodology,” in Signal Processing Applicationsand Technology, 1994.