Language Design for Implementing Process Scheduling Hierarchies
Julia L. LawallDIKU, University of Copenhagen
Gilles Muller, Hervé DuchesneEcole des Mines de Nantes
2
Setting: a Domain-Specific Language (DSL)– Advantages of a DSL:
Problem:– How to lift a DSL with new features while
maintaining these advantages?
The language extension problem
Programmability
VerificationDSL Optimization
Specifications
3
Our setting
Bossa: a DSL for implementing process schedulers– Process scheduler: an OS component that elects
a process to the CPU
CPUReady:
Blocked:
4
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!
5
A scheduling hierarchy
Round-robin for ordinary processes– Text editor, compiler, etc.
EDF for video player
Virtual scheduler: a scheduler of schedulers
Fixed-priorityvirtual scheduler
Round-robinprocess scheduler
EDFprocess scheduler
10 20
6
Features of Bossa:
How to lift Bossa to the programming of virtual schedulers while maintaining these features?
Extending Bossa to virtual schedulers
Programmability
VerificationDSL Optimization
Specifications
7
Overview
The scheduling domain The Bossa DSL
– Language features– Verifications
Lifting the DSL to a hierarchy– Language features– Verifications
8
Goal: elect a new process– Only ready processes are eligible for election
A scheduler must:– Elect an eligible process– Adjust process states in response to kernel events
Process scheduling
CPUReady:
Blocked:
9
The Bossa framework
Kernel(e.g., Linux)
SchedulingPolicy
elected process
Event notifications
block.*
unblock.*
bossa.schedule
10
Overview
The scheduling domain The Bossa DSL
– Language features– Verifications
Lifting the DSL to a hierarchy– Language features– Verifications
11
The Bossa DSL (main elements)
Process states– Describe process schedulability
States: running, ready, etc. State classes:
– RUNNING: the state of the running process– READY: states containing eligible processes– BLOCKED: states containing blocked processes
states = { RUNNING running : process; READY ready : sorted queue; READY expired : queue; BLOCKED blocked : queue; TERMINATED terminated;}
12
The Bossa DSL (main elements)
Event handlersOn unblock.* { e.target => ready; if (!empty(running)) running => ready;}
Scheduler
running ready blocked
p1 p2 p3
Scheduler
running ready blocked
p3p1 p2
unblock p2
13
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; } }}
14
Process election
On bossa.schedule { if (empty(ready)) { expired => ready; } select() => running;}
15
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;}
16
Verification example
On unblock.* { e.target => ready; if (!empty(running)) running => ready;}
Verification with respect to: [tgt in BLOCKED]→...
? in running? in ready
tgt in blocked
p in runningtgt in ready? in blocked
[] = runningtgt in ready? in blocked
[] = runningp,tgt in ready? in blocked
Matches: [p in RUNNING, tgt in BLOCKED]→ [[p,tgt] in READY]
[tgt in BLOCKED]→ [tgt in READY]
? in runningtgt in ready? in blocked
17
Overview
The scheduling domain The Bossa DSL
– Language features– Verifications
Lifting the DSL to a hierarchy– Language features– Verifications
18
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
19
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.
Fixed-priority
Round-robin EDF
p1 p2 p3 p4
running ready blocked running ready blocked
Round-robin is READY
EDF is BLOCKED
20
States for Fixed Priority
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
states = { RUNNING running : scheduler; READY ready : sorted queue; BLOCKED blocked : queue;}
21
Event handlers
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.
Fixed-priority
Round-robin EDF
unblock p3
p1 p2 p3 p4 p5
10 20
22
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;}
23
Execution model
If there are multiple states in a state class, a default is chosen.
VS
R D B
PS
R D B
p
VS
R D B
PS
R D B
p
VS
R D B
PS
R D B
p
forward
PS transition
returnREADY
VS transitionunblock p
24
Verification
Virtual scheduler event types must be consistent with process scheduler event types
Example: [tgt in BLOCKED]→[tgt in READY]
VS
R D B
PS1 PS2
R D BR D B
p1 p2
VS
R BD
PS1 PS2
R D BR D B
p1 p2
VS effect:[tgt in BLOCKED] →[tgt in READY]
unblockp2
25
Verification
Virtual scheduler event types must be consistent with process scheduler event types
Example: [tgt in BLOCKED]→[tgt in READY]
VS
R D B
PS1 PS2
R D BR D B
p1 p2
VS
R D B
PS1 PS2
R D BR D B
p1 p2
VS effect:[tgt in RUNNING] →[tgt in RUNNING]
unblockp2
26
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], ...
27
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
28
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.
Top Related