Clock Driven Schedulers

1 / 30

# Clock Driven Schedulers - PowerPoint PPT Presentation

Clock Driven Schedulers. Fred Kuhns Applied Research Laboratory Computer Science Washington University. Clock-Driven Approach. With periodic tasks, it is possible to statically determine a schedule: cyclic schedule implemented by a cyclic executive .

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

## PowerPoint Slideshow about 'Clock Driven Schedulers' - liam

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

### Clock Driven Schedulers

Fred Kuhns

Applied Research Laboratory

Computer Science

Washington University

Clock-Driven Approach
• With periodic tasks, it is possible to statically determine a schedule:
• cyclic schedule implemented by a cyclic executive.
• The cyclic schedule is a table listing jobs and their start times (aka decision time). Each job scheduled as a unit and is non-preemptable.
• Job may be function call, block of instructions, portion of procedure.
• Cyclic schedule (Table) defines a block of repeatable scheduling decisions where all deadlines and periods are met - Major Cycle.
• Timing decisions made only at frame boundaries.

Table

(Cyclic Schedule)

t1

...

tn

T(t1)

...

T(tn)

Example Timer-Driven Schedule

int MajorCycle = 10;

int entry = -1;

clock_handler () {

time_t next_time;

entry = (entry+1) % MajorCycle;

next_time= Table[entry].time

+ gettime();

if (gettime() > next_time)

return;

}

Creating a Model
• Major cycle can be divided into a sequence of fixed sized minor cycles (aka frames).
• Scheduling decisions are only made at frame boundaries.
• Exact start and completion time of jobs within frame is not known
• but must know the max computation time
• Jobs are allocated to specific frames
• Major cycle time corresponds to a Hyperperiod.
• If a schedule can not be found for the set of predefined jobs then they may need to be divided into job slices.
• divide job into a sequence of smaller jobs

Model Description
• N periodic tasks, where N is fixed
• Parameters of all periodic tasks known a priori
• assume interrelease time jitter negligible
• Ji,k (job k of task i) ready at its release timeri,k

Major Cycle

Minor Cycle (frame)

...

T1

T3

T2

T1

T4

T1

T3

T2

fn

f2

f1

Cyclic Executive runs in response to a tick event, bar shows time to execute scheduler

frame 3

frame 4

frame 5

frame 2

Constructing a Schedule

Cyclic Schedule

• Construct static schedule for a Major Cycle
• Cyclic Executive repeats this schedule segment
• There may be resulting idle intervals
• if so attempt to arrange so they occur periodically
• Static table lists frame fkand tasks to run tasksk (scheduling block),

f1

...

...

f5

T1 = ( 4, 1)

T2 = ( 5, 1.8)

T3 = (20, 1)

T4 = (20, 2)

H = 20

Major Cycle (Hyperperiod)

frame 1

T1

T3

T2

T1

T4

T2

T1

T2

T1

T1

T2

t = 0

4

8

12

16

20

Example Cyclic Executive

int MajorCycle = 10;

int MinorCycle = 1;

int frame=-1;

// tick handler,

// called at start of frame

ce_handler() {

time_t next_time = 0;

// ensure previous frame completed

if (previous execute_scheduler running)

handle_overrun(); // error

// determine frame and schedule

frame = (frame + 1) % MajorCycle;

next_time = gettime() + MinorCycle;

schedule = CyclicTable[frame].sched;

// sequentially run each job in schedule

execute_schedule(schedule);

// done with this frame

return;

}

execute_schedule (schedule) {

job_t job;

for each job in schedule

execute job

return

}

Partitioning Major Cycles into Frames
• choosing frame size,
• partitioning jobs into slices (if needed),
• placing jobs/slices into frames.
• Frames boundaries (start of frame) cyclic executive performs scheduling, monitoring and enforcement
• There is no preemption within frame
• Phase of every task instance is multiple of frame (j·f)
• first job of task starts on frame boundary, T = j·f.

T1

T3

T2

T1

T4

T2

T1

T2

T1

T1

T2

Hyperperiod, Major Cycle

Frame Size Constraints
• Every job can start and complete within a frame
• f ≥ max(ei), 1≤i≤ n
• Frame size divides H (the Hyperperiod)
• f divides pi for at least one value of i
• for a, x and k positive integers:ai·pi = H and x·f = pi k · f = H
• Between the release time and deadline of every job there is at least one frame
• t’ = release time of a job Jij; Dij = relative deadline of job Jij
• Want t + 2f ≤ t’ + Di or 2f - (t' - t) ≤ Di,
• but t' - t ≥ gcd(pi, f)
• if 2f - gcd(pi, f) ≤ Dithen 2f - (t' - t) ≤ Dimust be true.
• If t’ = t then it suffices if f ≤ Di.

fk+1

fk

fk+2

Jij feasible interval

t

t'

t+f

t+2f

t+3f

t'+Di

t'+pi

Foreground/Background
• Scheduling aperiodic jobs with periodic jobs
• Foreground jobs => periodic jobs already discussed
• background jobs => aperiodic jobs
• Aperiodic jobs
• executed within the idle blocks
• Aperiodic jobs are preemptable
• May optimize response time by scheduling within schedule slack time (slack stealing).

Slack Stealing
• Slack = f – xkwhere xk = total time allocated to periodic tasks in frame k and f = frame size
• Requirements may include some minimal aperiodic arrival rate
• Cyclic Exec executes aperiodic jobs as long as there is slack in the schedule.
• Periodic jobs must complete by deadline.

Slack Stealing

Release times:

A1 = 4

A2 = 9.5

A3 = 10.5

Periodic Jobs Only

Without Slack stealing

A2

A3

A1

A2

A3

With Slack stealing

A2

A3

A1

A2

A3

4

8

12

16

20

Simplifying Precedence Constraints
• To accommodate precedence and timing constraints derive a set of effective release times and deadlines
• Effective release time: no predecessors then equal to its release time. If predecessors then maximum of its own release time and the effective release times of its predecessor.

 = mean arrival rate

Departure

Dispatching

Service

Server

Modeling System
• Modeling the system for an average response time calculation
• Assume M/G/1 queuing model:
• Poisson arrival process (exponentially distributed inter-arrival times)
• General distribution function for service times
• Infinite queue, FIFO dispatch discipline
• Single server, single queue
• nT= # tasks; λimean arrival rate and ei mean execution time

λ = mean arrival rate, μ = mean service rate, Ts = 1/μ (service time)

ρ= λ/μ= utilization, w = items in Q, Tw = mean waiting time in Q,

q = total number of items in system,

Tq = Tw + Ts = total time waiting in system

Average Response Time

...

B1

B2

B3

B4

BN

• View as one large sample space comprised of the individual aperiodic Task sample spaces (used to calculate average and second moments, E[Bi] and E[Bi2]). Let N = nT in the above diagram.
• U = total utilization of periodic jobs. So (1-U) is the fraction of processor time available for aperiodic jobs. Thus UA must be < (1-U).
• Individual events scale by 1/(1-U):
• eAi = Bi/(1-U)

na

i

W =

(i/ ) * E[Bi]/(1-U) + W0 / {(1-U)2[( 1 - UA/(1-U)]}

na

i

Average Response Time
• Average queuing time inversely proportional to the square of the aperiodic bandwidth (1-U).
• Can improve average response of some jobs by using priority queues. Average queuing time increases with variance (E[x**2] = E[x] + Variance[x])
• Average response time W

Average service time Ts

Averaging queuing time Tw

i * E[Bi2]/2 = W0

Wait time versus Aperiodic Utilization

periodic Utilization

• represent as S(d,e): d = deadline, e = execution time
• minimum interrelease times and maximum execution time are not known in advance
• maximum execution time is known on release
• jobs are preemptable
• Apply an acceptance test at run time
• When job is released, determine if there is a feasible schedule that includes this sporadic job
• If no feasible schedule, then reject job and notify application of rejection

Performing an Acceptance Test
• S(d,e)released at time t in frame x-1:
• for example an interrupt is received in frame x-1.
• The deadline d is in frame (y+1) =>
• S must complete before frame y+1 begins
• Current total slack time available between frames x and y (inclusive) = Qc(x, y)
• S is rejected if
• e > Qc(x, y), OR
• some previously accepted jobs will not meet deadline
• Order waiting jobs using EDF

• EDF: priority driven scheduling algorithm with dynamic task (fixed job) priority assignment.
• earlier the deadline, higher the priority
• priorities are assigned on job release
• Jobs placed in run queue by priority
• Assumptions:
• Tasks are preemptable and independent
• Single Processor
• Optimal: EDF can produce a feasible schedule for a set of Jobs J if and only if J has a feasible schedule.

Latest Release Time (LRT)
• Goes "backwards" in time: Treats release times as deadlines and deadlines as release times.
• job with latest release time has highest priority
• Assume jobs are preemptable
• May leave processor idle when jobs are ready, so not a priority-driven algorithm.
• Optimal: LRT can produce feasible schedule for a set of jobs J if and only if feasible schedules for J exist.

Idle

J1, 3 (0, 6]

J2, 2 (5, 8]

J3, 2 (2, 7]

J1

J3

J2

1

4

6

8

Least Slack Time First (LST)
• LST or Maximum Laxity First (MLF)
• Dispatch job with minimum slack time: smaller slack time, higher priority.
• Optimal: Can produce feasible schedules for J if and only if feasible schedules for J exist.
• Requires knowledge of execution times, while EDF does not.
• Consequently may underutilize processor when using maximum (worst-case) analysis.

Performing and Acceptance Test
• Beginning of each frame: perform acceptance test on any waiting sporadic tasks
• Two steps:
• Determine if sporadic task can complete execution using available slack time (subtract any slack time used by accepted tasks with deadlines before d)

Implementation: Calculating Slack Time
• Calculating the available slack time
• S was released within previous frame, (x - 1)
• S has deadline in frame (y + 1)so must complete execution no later than frame y
• Acceptance test performed at start of frame x
• calculated between frame x and frame immediately preceding deadline, frame y
• if deadline is in frame x then S can not be scheduled
• Suffices to know original slack time between all frame pairs within one major cycle, Q(x, y) for x, y in H.
• Assume x is in major cycle j and y is in major cycle k
• Q(x,y) = Q(x,F) + Q(1,y) + [(k - 1) - j]Q(1,F); k > j
• Q(x, y) is known if k = j, y > x.
• Q(x, x) = is known, slack in current frame

Accepting S: Step 1
• If sporadic jobs are already in system then the available slack time is given by:

Qc(x, y) = Q(x, y) - Sum[dkd; (ek - e'k)]

slack minus remaining execution time of higher priority tasks.

e'k = time job k has already executed

The sum is over all jobs with deadline dk d.

• If S is accepted

Qs = Qc(x, y) – e

if job is accepted then store value with job

if (Qs< 0) then reject

else continue

Accepting S: Step 2
• Check all jobs with deadlines after d to verify they will not miss their deadlines.
• Accept if Step one is valid and the following condition is valid
• Ql- e 0 for all sporadic jobs with dl>d

Summary Acceptance Test
• Scheduler must store the following
• Precomputed slack table, Q(x, y), {x ,y = 1, 2, ..., F}
• Completed execution time of accepted sporadic jobs, e'k
• Current slack (Qs) of every sporadic job
• Optimality of Cyclic EDF (on-line algorithm)
• it is optimal compared to other schemes that perform an acceptance test at beginning of frames
• Not optimal compared to algorithms performing acceptance tests at arbitrary times.
• However, this may impact the periodic tasks which may be interrupted an arbitrary number of times in order to perform acceptance tests for released sporadic jobs.

Practical Considerations
• Frame Overruns
• Abort job, schedule recovery job
• Execute unfinished portion as aperiodic job
• Continue executing job
• Mode changes: system reconfiguration. Assume periodic jobs are independent

Assessing Clock-Driven Scheduling
• Simplicity: account for dependencies and resource contention. No need for synchronization mechanisms.
• Timing constraints verified or enforced at frame boundaries while minimizing overhead due to context switches and IPC mechanisms. Simple scheduling algorithm to minimize overhead.
• Minimal impact of asynchronous system processing (interrupts for example)
• often verification is simple