1. Language Design for Implementing Process Scheduling Hierarchies Julia L. Lawall DIKU, University of Copenhagen Gilles Muller, Hervé Duchesne Ecole des Mines de Nantes

2. 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 Verification DSL Optimization Specifications

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

4. 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. 5 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 Round-robin process scheduler EDF process scheduler 1020

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

7. 7 Overview  The scheduling domain  The Bossa DSL –Language features –Verifications  Lifting the DSL to a hierarchy –Language features –Verifications

8. 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 CPU Ready: Blocked:

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

10. 10 Overview  The scheduling domain  The Bossa DSL –Language features –Verifications  Lifting the DSL to a hierarchy –Language features –Verifications

11. 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. 12 The Bossa DSL (main elements)  Event handlers On unblock.* { e.target => ready; if (!empty(running)) running => ready; } Scheduler runningreadyblocked p1p2p3 Scheduler runningreadyblocked p3p1p2 unblock p2

13. 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. 14 Process election On bossa.schedule { if (empty(ready)) { expired => ready; } select() => running; }

15. 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. 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 running tgt in ready ? in blocked [] = running tgt in ready ? in blocked [] = running p,tgt in ready ? in blocked Matches: [p in RUNNING, tgt in BLOCKED]→ [[p,tgt] in READY] [tgt in BLOCKED]→ [tgt in READY] ? in running tgt in ready ? in blocked

17. 17 Overview  The scheduling domain  The Bossa DSL –Language features –Verifications  Lifting the DSL to a hierarchy –Language features –Verifications

18. 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-robinEDF

19. 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-robinEDF p1p2p3p4 runningreadyblocked runningreadyblocked Round-robin is READY EDF is BLOCKED

20. 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. 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 p1p2p3 p4p5 1020

22. 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. 23 Execution model  If there are multiple states in a state class, a default is chosen. VS RDB PS RDB p VS RDB PS RDB p VS RDB PS RDB p forward PS transition return READY VS transition unblock p

24. 24 Verification  Virtual scheduler event types must be consistent with process scheduler event types  Example: [tgt in BLOCKED]→[tgt in READY] VS RDB PS1PS2 RDBRDB p1p2 VS RBD PS1PS2 RDBRDB p1p2 VS effect: [tgt in BLOCKED] → [tgt in READY] unblock p2

25. 25 Verification  Virtual scheduler event types must be consistent with process scheduler event types  Example: [tgt in BLOCKED]→[tgt in READY] VS RDB PS1PS2 RDBRDB p1p2 VS RDB PS1PS2 RDBRDB p1p2 VS effect: [tgt in RUNNING] → [tgt in RUNNING] unblock p2

26. 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. 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. 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.