Language Design for Implementing Process Scheduling Hierarchies
description
Transcript of Language Design for Implementing Process Scheduling Hierarchies
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.