Vous êtes sur la page 1sur 30

Washington

WASHINGTON UNIVERSITY IN ST LOUIS


Clock Driven Schedulers
Fred Kuhns
Applied Research Laboratory
Computer Science
Washington University
2 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
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.
3 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Example Timer-Driven Schedule
int MajorCycle = 10;
int entry = -1;

clock_handler () {
time_t next_time;
current = Table[entry].task;
entry = (entry+1) % MajorCycle;
next_time = Table[entry].time
+ gettime();
execute_task(current);
if (gettime() > next_time)
handle_overload();
return;
}
t
1
T(t
1
)
...

...
t
n
T(t
n
)
Table
(Cyclic Schedule)
4 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
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
5 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Model Description
Periodic task model:
N periodic tasks, where N is fixed
Parameters of all periodic tasks known a priori
assume interrelease time jitter negligible
J
i,k
(job k of task i) ready at its release time r
i,k
f
1

f
2
f
n

...
Cyclic Executive runs in response to a tick event, bar shows time to execute scheduler
T
1
T
2
T
3
T
1
T
4
T
1
T
2
T
3
Minor Cycle (frame)
Major Cycle
6 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Constructing a 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 f
k
and tasks to run
tasks
k
(scheduling block),
T
1
T
2
T
3
T
4
T
1
T
2
T
1
T
2
T
1
T
1
T
2
4 8 12 16 20
Task = ( r, e)
T
1
= ( 4, 1)
T
2
= ( 5, 1.8)
T
3
= (20, 1)
T
4
= (20, 2)
H = 20
f
1
tasks
1
...

...
f
5
tasks
5
Cyclic Schedule
frame 1 frame 2 frame 3 frame 4 frame 5
Major Cycle (Hyperperiod)
t = 0
7 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
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
}
8 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Partitioning Major Cycles into Frames
Three tasks:
1. choosing frame size,
2. partitioning jobs into slices (if needed),
3. 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 (jf)
first job of task starts on frame boundary,
T
= jf.
T
1
T
2
T
3
T
4
T
1
T
2
T
1
T
2
T
1
T
1
T
2
Hyperperiod, Major Cycle
9 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Frame Size Constraints
1. Every job can start and complete within a frame
f max(e
i
), 1i n
2. Frame size divides H (the Hyperperiod)
f divides p
i
for at least one value of i
for a, x and k positive integers:
a
i
p
i
= H and xf = p
i
k f = H
3. Between the release time and deadline of every job there is at least
one frame
t = release time of a job J
ij;
D
ij
= relative deadline of job J
ij

Want t + 2f t + D
i
or 2f - (t' - t) D
i
,
but t' - t gcd(p
i
, f)
if 2f - gcd(p
i
, f) D
i
then 2f - (t' - t) D
i
must be true.
If t = t then it suffices if f D
i
.
t t'
f
k+1
f
k
f
k+2
t+f t+3f t+2f t'+D
i
t'+p
i
J
ij
feasible interval
10 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
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).
11 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Slack Stealing
Slack = f x
k
where
x
k
= 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.
12 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Slack Stealing
Without Slack stealing
With Slack stealing
A
1
A
2
A
2
A
3
A
3
A
1
A
2
A
2
A
3
A
3
Periodic Jobs Only
Release times:
A
1
= 4


A
2
= 9.5
A
3
= 10.5
4

8

12

16

20

13 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
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.

Effective deadline: No successor, then equal to
its original deadline. Otherwise minimum of its
deadline the effective deadlines of its
successors.
14 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
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
n
T
= # tasks;
i
mean arrival rate and e
i
mean execution time
= mean arrival rate, = mean service rate, T
s
= 1/ (service time)


= /

= utilization, w = items in Q, T
w
= mean waiting time in Q,
q = total number of items in system,
T
q
= T
w
+ T
s
= total time waiting in system
= mean arrival rate
Departure Dispatching
Service
Server
15 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Average Response Time
View as one large sample space comprised of
the individual aperiodic Task sample spaces
(used to calculate average and second moments,
E[B
i
] and E[B
i
2
]). Let N = n
T
in the above
diagram.
U = total utilization of periodic jobs. So (1-U) is
the fraction of processor time available for
aperiodic jobs. Thus U
A
must be < (1-U).
Individual events scale by 1/(1-U):
e
Ai
= B
i
/(1-U)
B
1
B
2
B
3
B
N
B
4
...

=
=
=
=
= =
=
|
.
|

\
|

=
=
T
T
T
n
i
i i A
i i
i
i
i
s
n
i
i i
s
n
i
i
E U
E
p
e
u
T
U
E
T
1
1
1
] [
] [
1
] [
|
|

|


16 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
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

i
n
a

i
* E[B
i
2
]/2 = W
0
i
n
a
(
i
/ ) * E[B
i
]/(1-U) + W
0
/ {(1-U)
2
[( 1 - U
A
/(1-U)]} W =

Averaging queuing time T
w
Average service time T
s
17 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Wait time versus Aperiodic Utilization
0
50
100
150
200
250
0.00 0.10 0.20 0.30 0.40 0.50 0.60 0.70 0.80 0.90
U
a
(aperiodic Utilization)
N
o
r
m
a
l
i
z
e
d

W
a
i
t

T
i
m
e
U = .2 U = .6
U = .4
U = .8
U = .9
periodic Utilization
18 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Scheduling Sporadic Jobs
Sporadic jobs
represent as S(d,e): d = deadline, e = execution time
have hard deadlines,
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
19 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
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) = Q
c
(x, y)
S is rejected if
e > Q
c
(x, y), OR
some previously accepted jobs will not meet deadline
Order waiting jobs using EDF
20 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Earliest Deadline First (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
Tasks have arbitrary release times, arbitrary deadlines
Single Processor
Optimal: EDF can produce a feasible schedule for a
set of Jobs J if and only if J has a feasible
schedule.
21 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
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.
J
1
J
2
J
3
1 4 6 8
J
1
, 3 (0, 6]
J
2
, 2 (5, 8]
J
3
, 2 (2, 7]
Idle
22 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
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.

23 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
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)
Determine if any already accepted sporadic tasks with
deadlines after d will be affected

24 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
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
25 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Accepting S: Step 1
If sporadic jobs are already in system then the
available slack time is given by:
Q
c
(x, y) = Q(x, y) - Sum[d
k
sd; (e
k
- 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 d
k
s d.

If S is accepted
Slack before new sporadic job's deadline:
Q
s
= Q
c
(x, y) e
if job is accepted then store value with job
if (Q
s
< 0) then reject
else continue
26 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Accepting S: Step 2
Check all jobs with deadlines after d to verify
they will not miss their deadlines.
d = deadline of new sporadic task
e = execution time of new sporadic task
Let S
l
= an already accepted sporadic task with
deadline d
l
> d.
Let Q
l
= calculated slack for sporadic tasks in S
l
Accept if Step one is valid and the following
condition is valid
Q
l
- e > 0 for all sporadic jobs with d
l
>d
27 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
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 (Q
s
) 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.
28 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
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
Hard-deadline:
Soft-deadline:
Other Workloads
29 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Assessing Clock-Driven Scheduling
Advantages:
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
30 Fred Kuhns (4/29/2012) CSE522S Advanced Operating Systems
Assessing Clock-Driven Scheduling
Disadvantages:
inflexible
Model and implementation may be too simple and
restrictive
Difficult to add new components or change existing
system parameters
Release times must be fixed
Must know all periodic parameters in advance
operation modes must be explicitly enumerated and
scheduled

Vous aimerez peut-être aussi