Distributed Credit-based Non-Preemptive Resource Management Scheme for

Hard Real-time Systems

林鼎原Department of Electrical Engineering

National Cheng Kung UniversityTainan, Taiwan, R.O.C

112/04/18

1

2

Abstract(1/1)The shift to multicore platforms due to growing computational load

requirements has made resource management a hot topic. This paper proposes one such distributed non-preemptive resource

management scheme that is based on credit (execution) budget allocation.Our simple and efficient scheme is a complete whole consisting of credit

allocation and enforcement protocols as well as its own customized admission controller.

The system is characterized by hard real-time behavior. Simulation results contrasted with the control case of self-timed approach

have shown that our scheme functions correctly and efficiently allowing all admitted applications to attain their performance requirements.

3

Specifications and Modeling Techniques(1/4)Both development and illustration of our approach is based on the model

of a 6-core heterogeneous multiprocessor platform and 4 applications of two distinct types (JPEG and H263).

The cores are named ARM7, ARM8, ARM9,ARM10, MIPS and FPGA. Our results are also directly applicable to homogeneous platforms.

Applications are modeled using synchronous dataflow (SDF) graphs as in figure 2.

In the graph an application is split into operations or tasks (A1, A2 ...) shown as circles containing the number of time units required for actor execution (Ex.Time).

These tasks are henceforth consistently referred to as actors in accordance with SDF terminology.

Figure 2. SDF graphs for applications A and B

4

Specifications and Modeling Techniques(2/4)Actors consume and produce tokens in quantities that are specified on the

transition arrows, at, respectively, the input and output of each actor.Depending on its rate of token production an actor may have to execute

multiple times per application iteration in order to satisfy data dependencies

(e.g. A1 has to execute 6 times to get A2 started). The number of times each actor has to execute in a single application

iteration is specified by the repetition vector:

e.g. for application A in figure 2 . ( 參照下頁補充 )an actor, usually the first in application data flow, may have initial tokens

shown as black dots on the arrows. The availability of initial tokens reflects the initial state of the application.

5

( 補充 )The execution of an actor is referred to as a (actor) firing, Communicated data and control signals are modeled as tokensThe amounts of tokens produced and consumed in a firing are referred to

as rates.balance equation:

Firings(Ai)*Production Rate(Ai) = Firings(Aj)* Consumption Rate(Aj) →EX : actor A1 到 A2 ， Firings(A1)*1=Firings(A2)*6 →

Firings(A1):Firings(A2)=6:1 A1 在一個 iteration 必須重複執行六次 A2 才能開始執行。

Figure 2. SDF graphs for applications A and B

6

Specifications and Modeling Techniques(3/4)Our case-study includes two types of applications:

JPEG and H263 decoders divided into 6 and 4 actors respectively.

Figure 3. SDF graphs for JPEG and H263 applications

7

Specifications and Modeling Techniques(4/4)

Table I : Specifics Of Case-Study Applications

8

Performance metricsPerformance requirements are expressed in terms of required application

period (Reqd.Period). We update the period Achvd.Period after every completed iteration by

keeping track of iteration count and Time defined as the difference between the current time and the previous period update time.

The period is the average of time intervals Time elapsed between completed iterations of an application

The required and achieved throughputs are defined as the reciprocals of

the Reqd.Period and Achvd.Period respectively:

Iter.CountTime.PeriodPrev.AchvdIter.Count

odAchvd.Peri)(Δ1)-(

.PeriodReqd/Achvd1

t.ThroughpuReqd/Achvd

Table IIAPPLICATION-LEVEL SPECIFICATIONS OF OFFERED USE-CASE

EX: Reqd.Throughput (JPEG1)= 1/115200 =8.68 *10^(-6)

9

Distributed Resource Management With CreditsThe proposed RM scheme consists of three integral parts:

admission control credit allocation. credit update

credit update is done locally on individual processors of the multicore system.

10

Credit Allocation Protocol(1/2)Credits are allocated to actors of an application by the RM upon entry of

that application into the system. One credit gives an actor permission for a single execution.

Credit distribution remains unchanged as long as the running use-case is unaltered (i.e. static use-case).

The use-case may be altered through applications’ entering or leaving the system.

11

Credit Allocation Protocol(2/2)The number of credits allocated to each actor of an admissible application is

based on the actor-level and application-level requirements The application-level requirement is the relative throughput factor derived from the

application’s performance requirements and use-case specifics The relative throughput factor :

Use case{1,2} RTF=8.68/4.60 The actor-level requirement is the actor frequency as specified by the topology of the

application’s SDF graph.

eutInUseCasqdThroughpSmallestRe

hputReqdThrougRTF

12

Credit Update Protocol(1/5)Credit update, or more accurately credit reload, is done locally, at the

individual processors. Actor credits are reloaded,

i.e. restored to the level initially determined by the RM, only when the credits of all actors on a given processor have been exhausted.

Let us call this principle collective progress dependent credit update (CPDCU).The mechanics of CPDCU is best described using an illustrative

hypothetical use-case as an example. Let there be two applications, A and B, with SDF graphs as shown in figure 2. For clarity the unfolded SDF graphs from figure 2 with corresponding processor actor

mapping are presented in figure 4.

Figure 2. SDF graphs for applications A and B

13

Credit Update Protocol(2/5)With no CPDCU in place (equivalent to unlimited credit) the system would

be self-timed. Consider actors A1 from application A and B1 from application B sharing

processor P1 as an example (area of focus indicated in figure 4).Occupation of this processor in time in self-timed mode is shown in figure 5.

Figure 4. Actor mapping of applications in figure 2

Figure 5. P1 occupation in self-timed mode (unlimited credit assumption) for use-case from figure 2

14

Credit Update Protocol(3/5)As is specified by the repetition vectors of applications A and B, (6 1 1)and(1 1)respectively

for a single iteration of application A, A1 has to execute six times whereas B1 must fire only once to make B happen.

With B1 constantly interleaving between the executions of A1, application B begins its 7th iteration when A has just finished its 1st.

Hence alternating execution of B1 and A1 resulting from this hands-off self-timed approach clearly puts A into a disadvantageous position throughput wise.

15

Credit Update Protocol(4/5)Occupation of the same processor in time as shown in figure 6 with

CPDCU implemented is fundamentally different.The CPDCU mechanism checks the overactive execution rate of B1

i.e. B1 is allowed to execute just two times before A1 has completed its 6th execution. The time between two consecutive credit reloads may be divided into the concurrent execution (CE) phase and the waiting phase.

The CE phase is the time interval in which all actors have executed the number of times equal to the lowest credits budget on the processor

The waiting phase is the period from the end of the CE phase to the next credit reload.

Figure 6.P1 occupation in CPDCU mode for use-case from figure 2

16

Credit Update Protocol(5/5)During the waiting phase on P1(processor1), A1 gets the chance to

complete the remaining executions (i.e. exhaust its credits) unhindered by B1 since the latter is stalled by our mechanism.

Execution requests of actors with zero credit get wait-listed and upon credit reload are executed in the first-come-first-served manner

17

Admission Control(1/8)The admission control protocol has been developed based on the typical

two-phase execution scenario (figure 6). The entire admission control protocol expressed in pseudo code is presented in

algorithm 1.

18

Admission Control(2/8) For stage 0:

Stage 0 is the derivation of parametric equation(s) based on actor graph analysis.

//當新的應用程式進入時， admission controller 便會啟動

19

Admission Control(3/8) For stage 1:Stage 1 is the analysis of the CE phase of processor occupation from the

model scenario. Hence the system is being considered as self-timed ignoring the waiting phase

phenomenon introduced by the CPDCU

/* 將新的應用程式和原本程式一起做整體分析考量 */

//若應用程式預估的週期≦所需的週期，則允許此新進的應用程式

20

Admission Control(4/8)In stage 1 estimates of the application periods are made

assuming concurrent actor execution by substituting worst-case actor response time into the apriori (stage 0) derived parametric equations of individual applications

(lines 6-10). The role of the admission controller is to evaluate the timing constraints of

the new applications against available resources. If the available resources of the platform are less than the timing requirement of the new

application, the admission controller rejects the request

If the resultant period estimates of all applications are smaller or equal to their required periods

the proposed use-case has passed stage 1 (lines 11-12) Otherwise the request for new application admission is immediately denied (lines 13-16).

21

Admission Control(5/8) For stage 2: we analyse the characteristic feature of the waiting phase.

// 通過 stage1 ， predicted. Period ≦Reqd.Period 故 Slack≧0

22

Admission Control(6/8)This stage introduces the notion of slack (line 20):

slack of an application is the difference between the required period and the stage 1 estimate.

Slack(App) = Reqd.Period (App) - PredictedPeriod(App) Further analysis of stage 2 is based on the premise that the positive slack may be spent

waiting by the application.

The estimated waiting time is the product of the largest difference in credits on a processor and the execution time (Ex.Time) of the actor with the most credits on the same processor.

Waiting time =(ΔmaxCredits ) * (Ex.Time) EX: credits(A1)=6; credits(B1)=2 ， waiting time=(6-2)*1 =4 個單位時間

Figure 6.P1 occupation in CPDCU mode for use-case from figure 2

23

Admission Control(7/8)The definition of the waiting phase is tied to the view point of the actor with

the least credits. because that one, under normal circumstances, exhausts its credits first and hence

its waiting time is the bottleneck. The least amount of credits faces the effects of the waiting phase (e.g. actor B1 in

figure 6)If this bottleneck fits into the portion of the corresponding application’s

slack that the lowest credit actor of the processor may count on, the application has passed stage 2 on that particular processor (line 26-31).

24

Admission Control(8/8)Exactly how big the allocated portion of application’s slack for the

bottleneck actor of processor Pi would be,is determined by the Relative Importance Fraction (RIF) (line 24):

the fraction of the total (sequential) application period (Seq.Period) time spent executing this actor.

bottleneck Actor 執行時間 佔 整個 application 週期時間 的比例