1. The Design of an EDF- Scheduled Resource-Sharing Open Environment Nathan Fisher Wayne State University Marko Bertogna Scuola Superiore Santa’Anna of Pisa Sanjoy Baruah The University of North Carolina at Chapel Hill

2. Outline Background: Open Environments. Motivation. Challenge. Prior Work. Our Results: System Model. Resource-Sharing Framework: Formal Properties. Summary & Future Work. System Scheduler. Validation Tests. Techniques for Minimizing “Blocking.”

3. Outline Background: Open Environments. Motivation. Challenge. Prior Work. Our Results: System Model. Resource-Sharing Framework: Formal Properties. Summary & Future Work.

4. Motivation: Traditional Real-Time System Design Application A: 11 22 33 Application B: ’1’1 ’2’2 Real-Time Tasks Background – Prior Work– Our Results– Summary

5. Motivation: Traditional Real-Time System Design Application A: 11 22 33 Application B: ’1’1 ’2’2 CPU Scheduler Schedulability Test Task Specifications Background – Prior Work– Our Results– Summary

6. Motivation: Traditional Real-Time System Design Application A: 11 22 33 Application B: ’1’1 ’2’2 CPU Scheduler Each task submits jobs directly to CPU scheduler. Assumption: All tasks of all real- time applications are known at system-validation time. Background – Prior Work– Our Results– Summary

7. Motivation: Traditional Real-Time System Design Drawbacks: 1.All tasks in the system need to be validated together and known to system designer, a priori. Monolithic system design. 2.Each application on shared platform must use same scheduling algorithm. 3.Temporally-bad behavior of one task may affect other tasks. Violation of System Design Principles: Encapsulation & Abstraction. Modularity & Hierarchical Design. Fault-containment. Solution? Background – Prior Work– Our Results– Summary

8. Virtual Processor B Local Scheduler Virtual Processor A Local Scheduler Motivation: Real-Time Open Environments CPU Scheduler Application Interface: VP Speed. Jitter tolerance. … Application A: 11 22 33 Application B: ’1’1 ’2’2 IAIA IBIB Global Background – Prior Work– Our Results– Summary

9. Motivation: Real-Time Open Environments CPU Scheduler Application A: 11 22 33 Virtual Processor A Application B: ’1’1 ’2’2 Virtual Processor B Local Scheduler Local Scheduler IAIA IBIB Application-Level Schedulability Test Global Background – Prior Work– Our Results– Summary

10. Motivation: Real-Time Open Environments CPU Scheduler Application A: 11 22 33 Virtual Processor A Application B: ’1’1 ’2’2 Virtual Processor B Local Scheduler Local Scheduler IAIA IBIB Application-Level Schedulability Test Each application independently developed & validated. Global Background – Prior Work– Our Results– Summary

11. Motivation: Real-Time Open Environments CPU Scheduler Application A: 11 22 33 Virtual Processor A Application B: ’1’1 ’2’2 Virtual Processor B Local Scheduler Local Scheduler IAIA IBIB Composability Test Global Background – Prior Work– Our Results– Summary

12. Motivation: Real-Time Open Environments CPU Scheduler Application A: 11 22 33 Virtual Processor A Application B: ’1’1 ’2’2 Virtual Processor B Local Scheduler Local Scheduler IAIA IBIB Global Background – Prior Work– Our Results– Summary

13. Motivation: Real-Time Open Environments Advantages: 1.Application’s temporal constraints may be validated independently and need not be known a priori. Component-based design. Service-oriented design. 2.Each application on shared platform may use different scheduling algorithm. 3.Virtual processors isolate temporally-bad behavior of an application. Adherence to System Design Principles: Encapsulation & Abstraction. Modularity & Hierarchical Design. Fault-containment. Background – Prior Work– Our Results– Summary

14. Challenge: Real-Time Open Environments CPU Scheduler Application A: 11 22 33 Application Server A Application B: ’1’1 ’2’2 Application Server B Local Scheduler Local Scheduler IAIA IBIB Global R1R1R1R1 R2R2R2R2 RmRmRmRm … Challenge: Tasks may access shared global resources. Implication: Applications not completely independent. Background – Prior Work– Our Results– Summary

15. Prior Work: Real-Time Open Environments “First Generation” Open Environments: Examples: Resource Kernels [Rajkumar et al., MMCM 1998]. Resource Partitions [Mok, Feng, & Chen, RTAS 2001]. Periodic Resource Model [Shin & Lee, RTSS 2003]. … Periodic tasks. Not all consider shared resources. [Deng & Liu, RTSS 1997] Background – Prior Work– Our Results– Summary

16. Prior Work: Real-Time Open Environments “Second Generation” Open Environments: Recent Work: Davis & Burns [RTSS 2006]. Behnam et al. [RTSS-WiP 2006]. … Sporadic tasks. Non-preemptive sharing of global resources. [Deng & Liu, RTSS 1997] Drawback: May cause blocking among & within applications. Our Work: Allow for preemptive sharing (when needed). Background – Prior Work– Our Results– Summary

17. Our Results: System Model Applications: A 1, A 2, …, A q. Global Resources: R 1, R 2, …, R m. Application Interface for A k : I A = (  k,  k, H k (  ))  k : virtual processor speed.  k : jitter tolerance. H k (R ℓ ): A k ’s resource-hold time of R ℓ. Each application A k comprised of sporadic tasks system  (A k ). Background – Prior Work– Our Results– Summary k Maximum continuous interval that A k may lock R ℓ.

18. (e i ) 0 pipi 2p i 3p i 4p i  i = (e i,d i,p i ) time Our Results: System Model Sporadic Task Model Relative Deadline Period Worst case Execution Requirement Task Systems for A k :  (A k ) = {  1,…,  n }

19. Our Results: System Model Applications: A 1, A 2, …, A q. Global Resources: R 1, R 2, …, R m. Each application comprised of sporadic tasks. Application Interface for A k : I A = (  k,  k, H k (  ))  k : virtual processor speed.  k : jitter tolerance. H k (R ℓ ): A k ’s resource-hold time of R ℓ. k

20. Our Results: Resource-Sharing Framework Bounded-delay Resource Open Environment (BROE) Server: Application virtual processor. Maintains 3 server variables for A k : E k : budget. P k : replenishment period. D k : server deadline. BROE Servers are scheduled by EDF plus Stack Resource Protocol (SRP) [Baker, 1991] w.r.t. server deadline and period. Background – Prior Work– Our Results– Summary

21. Our Results: Resource-Sharing Framework I A = (  k,  k, H k (  )) BROE Server Rules: 1. Initialize to “normal” replenishment values: Period: Maximum Budget: Deadline: kk For all intervals of size t >  k, execution over interval should be at least (t-  k )  k k P k = kk 2(1-  k ) E k = kkkk 2(1-  k ) D k = + t cur kk 2(1-  k ) Task system  (A k ) scheduled within server allocation by A k ’s local scheduler. Earlier-deadline applications are executing. Background – Prior Work– Our Results– Summary

22. Our Results: Resource-Sharing Framework BROE Server Rules: 1. Initialize to “normal” replenishment values. 2. If server is executing, budget is decremented at rate 1. Budget time 0 E k = -1, if A k executing, 0, otherwise. d dt I A = (  k,  k, H k (  )) k Background – Prior Work– Our Results– Summary

23. Our Results: Resource-Sharing Framework BROE Server Rules: 1. Initialize to “normal” replenishment values. 2. If server is executing, budget is decremented at rate 1. 3. If task of  (A k ) requests resource R ℓ when E k < H k (R ℓ ), then defer execution and update replenishment time & next deadline: Task requests R ℓ, but E k < H k (R ℓ ) Access to R ℓ is granted here  k Execution over interval > (t-  k )  k I A = (  k,  k, H k (  )) k Background – Prior Work– Our Results– Summary

24. Our Results: Formal Properties Composability Test: B k : largest H i (R ℓ ) value that can block A k. Theorem: Applications A 1, A 2, …, A q composable on a unit-speed processor if for all k  {1,…, q}:   j +  1 BkBk PkPk P j  P k Background – Prior Work– Our Results– Summary

25. Our Results: Formal Properties Composability Test: Local-Scheduler “Optimality”: Theorem: If A k independently validated on processor of speed  k and each job completes  k prior to its deadline, then it will meet all deadlines on BROE server with interface I A  (  k,  k, H k (  )) when using EDF + SRP. Theorem: Applications A 1, A 2, …, A q composable on a unit-speed processor if for all k  {1,…, q}:   j +  1 BkBk PkPk P j  P k Background – Prior Work– Our Results– Summary k

26. Our Results: Resource-Hold Times How do you determine H k (R ℓ )? 1.If  (A k ) feasible when non-preemptively executing R ℓ on VP, execute non-preemptively on BROE server. H k (R ℓ ) equals duration of longest critical section of  (A k ) on R ℓ. Background – Prior Work– Our Results– Summary

27. Our Results: Resource-Hold Times How do you determine H k (R ℓ )? 1.If  (A k ) feasible when non-preemptively executing R ℓ on VP, execute non-preemptively on BROE server. 2.If  (A k ) infeasible on VP using EDF+SRP, then by “optimality” theorem,  (A k ) cannot be scheduled on server of speed  k. 3.If neither above hold: devise local scheduling technique for minimizing application resource hold time. Previous paper [RTAS 2007] describes H k (R ℓ ) minimization for EDF+SRP. Background – Prior Work– Our Results– Summary

28. Our Results: Blocking Reduction Intra-application preemption + SRP: reduces blocking of “higher-priority” tasks. Deferring resource execution: prevents blocking after budget exhausted. Minimization of resource-hold times: reduces an application’s impact on other applications. Background – Prior Work– Our Results– Summary

29. Summary & Future Work Open Environments: System design benefits. Composability of independently-validated applications. Challenge: Shared Resources. Our Contributions: “Clean” interface. Simple composability test. Resource-hold times (allowing preemption, if needed). Future Work: Interface selection. General task models & different schedulers. Multiprocessor platforms.

30. Thank You! Questions?fishern@cs.wayne.edu