language design for implementing process scheduling hierarchies julia l. lawall diku, university of...

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.