Language Design for Implementing Process Scheduling Hierarchies

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: • Problem: • How to lift a DSL with new features while maintaining these advantages? Programmability DSL Optimization Verification Specifications

Ready: CPU Blocked: Our setting • Bossa: a DSL for implementing process schedulers • Process scheduler: an OS component that elects a process to the CPU

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!

A scheduling hierarchy • Round-robin for ordinary processes • Text editor, compiler, etc. • EDF for video player • Virtual scheduler: a scheduler of schedulers Fixed-priority virtual scheduler 10 20 Round-robin process scheduler EDF process scheduler

Extending Bossa to virtual schedulers • Features of Bossa: • How to lift Bossa to the programming of virtual schedulers while maintaining these features? Programmability DSL Optimization Verification Specifications

Overview • The scheduling domain • The Bossa DSL • Language features • Verifications • Lifting the DSL to a hierarchy • Language features • Verifications

Ready: CPU Blocked: Process scheduling • 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

The Bossa framework Event notifications Kernel (e.g., Linux) Scheduling Policy block.* unblock.* bossa.schedule elected process

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; }

The Bossa DSL (main elements) • Event handlers On unblock.* { e.target => ready; if (!empty(running)) running => ready; } unblock p2 Scheduler Scheduler running ready blocked running ready blocked p1 p2 p3 p1 p2 p3

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; } } }

Process election On bossa.schedule { if (empty(ready)){ expired => ready; } select() => running; }

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] Verification problem On unblock.* { e.target => ready; if (!empty(running)) running => ready; }

Verification example ? in running ? in ready tgt in blocked On unblock.* { e.target => ready; if (!empty(running)) running => ready; } ? in running tgt in ready ? in blocked Verification with respect to: [tgt in BLOCKED]→... p in running tgt in ready ? in blocked • Matches: • [p in RUNNING, • tgt in BLOCKED]→ • [[p,tgt] in READY] • [tgt in BLOCKED]→ • [tgt in READY] [] = running p,tgt in ready ? in blocked [] = running tgt in ready ? in blocked

Fixed-priority Round-robin EDF 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 running ready blocked running ready blocked p1 p2 p3 p4 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

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 = { RUNNINGrunning : scheduler; READYready : sorted queue; BLOCKEDblocked : queue; }

Event handlers Fixed-priority • 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. unblock p3 10 20 Round-robin EDF p1 p2 p3 p4 p5

New constructs • New constructs: • next(p) • Thechild scheduler managing process p • s => forwardImmediate() • Forward the event to scheduler s On unblock.* { next(e.target) => forwardImmediate(); if (!empty(running)) running => ready; }

VS transition VS VS VS return READY forward R R D D B B R D B PS PS PS PS transition R D B R D B R D B p p p Execution model • If there are multiple states in a state class, a default is chosen. unblock p

VS VS R D B R D B PS1 PS2 PS1 PS2 R D B R D B R D B R D B p1 p2 p1 p2 Verification • Virtual scheduler event types must be consistent with process scheduler event types • Example: [tgt in BLOCKED]→[tgt in READY] unblock p2 VS effect: [tgt in BLOCKED] →[tgt in READY]

VS VS R D B R D B PS1 PS2 PS1 PS2 R D B R D B R D B R D B p1 p2 p1 p2 Verification • Virtual scheduler event types must be consistent with process scheduler event types • Example: [tgt in BLOCKED]→[tgt in READY] unblock p2 VS effect: [tgt in RUNNING] →[tgt in RUNNING]

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], ...

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

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.

Language Design for Implementing Process Scheduling Hierarchies