The Design of an EDFScheduled ResourceSharing Open Environment

The Design of an EDFScheduled 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

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

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

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

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

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

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

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

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

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

Motivation: Real-Time Open Environments I Virtual Processor A A Application A: 1 2 Local Scheduler 3 Global Scheduler Virtual Processor B Application B: ’ 1 ’ 2 CPU Local Scheduler IB Background – Prior Work– Our Results– Summary

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

Challenge: Real-Time Open Challenge: Tasks may Environments I access shared global Application Server A A resources. Application A: 1 2 Implication: Applications not completely independent. Local Scheduler 3 Global Scheduler Application Server B Application B: ’ 1 ’ 2 R 1 R 2 … Rm CPU Local Scheduler IB Background – Prior Work– Our Results– Summary

Prior Work: Real-Time Open Environments [Deng & Liu, RTSS 1997] n “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. Background – Prior Work– Our Results– Summary

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

Our Results: System Model n n n Applications: A 1, A 2, …, Aq. Global Resources: R 1, R 2, …, Rm. Application Interface for Ak: IAk= ( k, Hk( )) Maximum continuous interval that Ak may lock Rℓ. • k: virtual processor speed. • k: jitter tolerance. • Hk(Rℓ): Ak’s resource-hold time of Rℓ. n Each application Ak comprised of sporadic tasks system (Ak). Background – Prior Work– Our Results– Summary

Our Results: Resource-Sharing Framework n Bounded-delay Resource Open Environment (BROE) Server: • Application virtual processor. • Maintains 3 server variables for Ak: • Ek: budget. • Pk: replenishment period. • Dk: 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

Our Results: Resource-Sharing Framework BROE Server Rules: IAk= ( k, Hk( )) Initialize to “normal” replenishment values: 1. • • • k Pk = 2(1 - ) Period: k k k E = Maximum Budget: k 2(1 - ) k k Deadline: Dk = 2(1 - ) + tcur k Task system (Ak) scheduled within server Earlier-deadline allocation by Ak’s local scheduler. applications are executing. For all intervals of size t >k k, execution over interval should be at least (t- k ) k Background – Prior Work– Our Results– Summary

Our Results: Resource-Sharing Framework BROE Server Rules: 1. 2. IAk= ( k, Hk( )) Initialize to “normal” replenishment values. If server is executing, budget is decremented at rate 1. -1, if Ak executing, d dt Budget 0 Ek = 0, otherwise. time Background – Prior Work– Our Results– Summary

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

Our Results: Formal Properties n Composability Test: Theorem: Applications A 1, A 2, …, Aq composable on a unit-speed processor if for all k {1, …, q}: j + Pj P k Bk Pk 1 Bk: largest Hi(Rℓ) value that can block Ak. Background – Prior Work– Our Results– Summary

Our Results: Formal Properties n Composability Test: Theorem: Applications A 1, A 2, …, Aq composable on a unit-speed processor if for all k {1, …, q}: j + Pj P k n Bk Pk 1 Local-Scheduler “Optimality”: Theorem: If Ak 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 IA k ( k, Hk( )) when using EDF + SRP. Background – Prior Work– Our Results– Summary

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

Our Results: Resource-Hold Times n How do you determine Hk(Rℓ)? 1. If (Ak) feasible when non-preemptively executing Rℓ on VP, execute non-preemptively on BROE server. 2. If (Ak) infeasible on VP using EDF+SRP, then by “optimality” theorem, (Ak) 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 Hk(Rℓ) minimization for EDF+SRP. Background – Prior Work– Our Results– Summary

Our Results: Blocking Reduction n 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

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

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