Language Design for Implementing
Process Scheduling Hierarchies
Julia L. Lawall
DIKU, University of Copenhagen
Gilles Muller, Hervé Duchesne
Ecole des Mines de Nantes
The language extension problem
 Setting:
a Domain-Specific Language (DSL)
– Advantages of a DSL:
Programmability
DSL
Optimization
Verification
Specifications
 Problem:
– How to lift a DSL with new features while
maintaining these advantages?
2
Our setting
 Bossa:
a DSL for implementing process
schedulers
– Process scheduler: an OS component that elects
a process to the CPU
Ready:
Blocked:
CPU
3
Some process scheduling policies
 Round-robin
– Each process gets a short fixed amount of time, then
moves to the end of a FIFO runqueue.
– Basis of Linux, Windows scheduling policies.
 Earliest-Deadline
First (EDF)
– Process declares period, deadline, and computation
time.
– Scheduler either guarantees the requested behavior or
rejects the process.
– Used for hard/soft real-time processes (eg video player)
 One
scheduling policy is not always enough!
4
A scheduling hierarchy
 Round-robin
for ordinary processes
– Text editor, compiler, etc.
 EDF
for video player
Fixed-priority
virtual scheduler
10
Round-robin
process scheduler
 Virtual
20
EDF
process scheduler
scheduler: a scheduler of schedulers
5
Extending Bossa to virtual schedulers
 Features
of Bossa:
Programmability
DSL
Optimization
Verification
Specifications
 How
to lift Bossa to the programming of
virtual schedulers while maintaining these
features?
6
Overview
 The
scheduling domain
 The Bossa DSL
– Language features
– Verifications
 Lifting
the DSL to a hierarchy
– Language features
– Verifications
7
Process scheduling
 Goal:
elect a new process
– Only ready processes are eligible for election
Ready:
CPU
Blocked:
 A scheduler
must:
– Elect an eligible process
8
– Adjust process states in response to kernel events
The Bossa framework
Event notifications
Kernel
(e.g., Linux)
block.*
unblock.*
bossa.schedule
Scheduling
Policy
elected process
9
Overview
 The
scheduling domain
 The Bossa DSL
– Language features
– Verifications
 Lifting
the DSL to a hierarchy
– Language features
– Verifications
10
The Bossa DSL (main elements)
 Process
states
– Describe process schedulability
states = {
RUNNING running : process;
READY
ready
: sorted queue;
READY
expired : queue;
BLOCKED blocked : queue;
TERMINATED terminated;
}
 States:
running, ready, etc.
 State classes:
– RUNNING: the state of the running process
– READY: states containing eligible processes
– BLOCKED: states containing blocked processes
11
The Bossa DSL (main elements)
 Event
handlers
On unblock.* {
e.target => ready;
if (!empty(running))
running => ready;
}
unblock p2
Scheduler
running
p1
ready
Scheduler
blocked
p2
p3
running
ready
p1
p2
blocked
p3
12
A more complex handler
On unblock.* {
e.target => ready;
if (!empty(running)) {
running.EVT =
running.AVT - running.current_warp;
e.target.EVT =
e.target.AVT - e.target.current_warp +
running.weighted_context_switch_allowance;
if (e.target > running) {
running => ready;
}
}
}
13
Process election
On bossa.schedule {
if (empty(ready)) {
expired => ready;
}
select() => running;
}
14
Verification problem
 How
should an event handler affect process states?
 Event types: describe required event-handler
behavior.
 Unblock.*
– [tgt in BLOCKED]→[tgt in READY]
– [p in RUNNING, tgt in BLOCKED]→
[[p,tgt] in READY]
On unblock.* {
e.target => ready;
if (!empty(running))
running => ready;
}
15
Verification example
On unblock.* {
e.target => ready;
if (!empty(running))
running => ready;
}
Verification with respect to:
[tgt in BLOCKED]→...
Matches:
[p in RUNNING,
tgt in BLOCKED]→
[[p,tgt] in READY]
[tgt in BLOCKED]→
[tgt in READY]
? in running
? in ready
tgt in blocked
? in running
tgt in ready
? in blocked
p in running
tgt in ready
? in blocked
[] = running
p,tgt in ready
? in blocked
[] = running
tgt in ready
? in blocked16
Overview
 The
scheduling domain
 The Bossa DSL
– Language features
– Verifications
 Lifting
the DSL to a hierarchy
– Language features
– Verifications
17
Virtual schedulers
 Virtual
scheduler (VS): a scheduler that
manages other schedulers
 States
– What is the state of a scheduler?
 Event
handlers
– How to propagate events through the
hierarchy?
Fixed-priority
Round-robin
EDF
18
Scheduler states
 Process
states record which processes are
eligible for election.
 Analogously, scheduler states record which
schedulers are managing processes that are
eligible for election.
Round-robin is READY
EDF is BLOCKED
Fixed-priority
Round-robin
running
EDF
ready
blocked
p1
p2
running
ready
blocked
p3
p4
19
States for Fixed Priority
states = {
RUNNING running : scheduler;
READY
ready
: sorted queue;
BLOCKED blocked : queue;
}
 State
classes:
– RUNNING: the child scheduler is managing the
running process
– READY: the child scheduler is not managing the
running process, but is managing some eligible process
(in the READY class)
– BLOCKED: the child scheduler is not managing the
running process or any eligible process
20
Event handlers
Fixed-priority
unblock p3
10
20
Round-robin
p1
p2
EDF
p3
p4
p5
 For
an event with a target process p, a VS
forwards the event toward p’s scheduler.
 For
bossa.schedule (process election), a VS
picks a READY child scheduler.
21
New constructs
 New
constructs:
– next(p)
» The child scheduler managing process p
– s => forwardImmediate()
» Forward the event to scheduler s
On unblock.* {
next(e.target) => forwardImmediate();
if (!empty(running))
running => ready;
}
22
Execution model
unblock p
VS
R
D
forward
B
R
D
PS
R
D
return
READY
B
VS
R
PS
B
p
 If
VS transition
VS
PS transition
R
D
p
D
B
PS
B
R
D
B
p
there are multiple states in a state class, a
default is chosen.
23
Verification
 Virtual
scheduler event types must be
consistent with process scheduler event types
 Example: [tgt in BLOCKED]→[tgt in READY]
unblock
p2
VS
R
D
PS1
R
p1
D
B
R
VS
B
R
D
PS2
PS1
PS2
D
B
R
p2
p1
D
B
R
D
p2
B
B VS
effect:
[tgt in BLOCKED]
→[tgt in READY]
24
Verification
 Virtual
scheduler event types must be
consistent with process scheduler event types
 Example: [tgt in BLOCKED]→[tgt in READY]
unblock
p2
VS
R
D
PS1
R
p1
D
B
p2
R
VS
B
R
PS2
PS1
D
B
R
p1
D
D
B
PS2
B
p2
R
D
B VS
effect:
[tgt in RUNNING]
→[tgt in RUNNING]
25
Constructing VS types
 Type
construction steps: [tgt in B]→ ...
– Distribute named processes among child schedulers
» [? in R, ? in D, tgt in B]
– Add possible other processes
» [p1 in R, p2 in D, tgt in B], [[] in R, p in D, tgt in B] ...
– Calculate output states
» [p1 in R, p2 in D, tgt in B] → [p1 in R, tgt,p2 in D, ? in B],
[[] in R, p in D, tgt in B] → [[] in R, tgt,p2 in D, ? in B], ...
– Compute starting and ending states of the scheduler
» [tgt in R] → [tgt in R], [tgt in D] → [tgt in D], ...
26
Generated VS types
 PS
type (unblock):
– [tgt in BLOCKED]→[tgt in READY]
 VS
types:
– [tgt in BLOCKED]→[tgt in READY]
– [tgt in READY]→[tgt in READY]
– [tgt in RUNNING]→[tgt in RUNNING]
 Verification
as before
27
Conclusions
 DSL makes
programming kernel-level internals
easy and safe
– Event types/verifications capture kernel expertise
 DSL +
automated support for extending the
verification makes hierarchy programming easy
and safe
 Achieves application-specific scheduling effects
in a modular way
– Video player can load and unload its own scheduler.
28