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.