the design of an edf- scheduled resource-sharing open environment nathan fisher wayne state...
TRANSCRIPT
The Design of an EDF-Scheduled Resource-Sharing Open EnvironmentNathan Fisher
Wayne State UniversityMarko Bertogna
Scuola Superiore Santa’Anna of Pisa
Sanjoy BaruahThe University of North Carolina at
Chapel Hill
Outline Background: Open Environments.
• Motivation.• Challenge.
Prior Work. Our Results:
• System Model.• Resource-Sharing Framework:• Formal Properties.
Summary & Future Work.
Motivation: Traditional Real-Time System Design
Application A:
1
2
3
Application B:
’1
’2
Real-Time Tasks
Background – Prior Work– Our Results– Summary
Motivation: Traditional Real-Time System Design
Application A:
1
2
3
Application B:
’1
’2
CPU Scheduler
Schedulability Test
Task
Specifications
Background – Prior Work– Our Results– Summary
Motivation: Traditional Real-Time System Design
Application A:
1
2
3
Application B:
’1
’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
Motivation: Traditional Real-Time System DesignDrawbacks:
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?Solution?
Background – Prior Work– Our Results– Summary
Virtual Processor BVirtual Processor B
LocalScheduler
Virtual Processor AVirtual Processor A
LocalScheduler
Motivation: Real-Time Open Environments
CPU Scheduler
Application Interface:• VP Speed.• Jitter tolerance.• …Application A:
1
2
3
Application B:
’1
’2
IA
IB
Global
Background – Prior Work– Our Results– Summary
Motivation: Real-Time Open Environments
CPU Scheduler
Application A:
1
2
3
Virtual Processor AVirtual Processor A
Application B:
’1
’2
Virtual Processor BVirtual Processor B
LocalScheduler
LocalScheduler
IA
IB
Application-LevelSchedulability Test
Global
Background – Prior Work– Our Results– Summary
Motivation: Real-Time Open Environments
CPU Scheduler
Application A:
1
2
3
Virtual Processor AVirtual Processor A
Application B:
’1
’2
Virtual Processor BVirtual Processor B
LocalScheduler
LocalScheduler
IA
IB Application-LevelSchedulability Test
Each application independently developed
& validated.
Global
Background – Prior Work– Our Results– Summary
Motivation: Real-Time Open Environments
CPU Scheduler
Application A:
1
2
3
Virtual Processor AVirtual Processor A
Application B:
’1
’2
Virtual Processor BVirtual Processor B
LocalScheduler
LocalScheduler
IA
IB
Composability Test
Global
Background – Prior Work– Our Results– Summary
Motivation: Real-Time Open Environments
CPU Scheduler
Application A:
1
2
3
Virtual Processor AVirtual Processor A
Application B:
’1
’2
Virtual Processor BVirtual Processor B
LocalScheduler
LocalScheduler
IA
IB
Global
Background – Prior Work– Our Results– Summary
Motivation: Real-Time Open EnvironmentsAdvantages:
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 Environments
CPU Scheduler
Application A:
1
2
3
Application Server AApplication Server A
Application B:
’1
’2
Application Server BApplication Server B
LocalScheduler
LocalScheduler
IA
IB
Global RR11 RR22 RRmm……
Challenge: Tasks may access shared global resources.
Implication: Applications not completely independent.
Background – Prior Work– Our Results– Summary
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
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
Our Results: System Model
Applications: A1, A2, …, Aq.
Global Resources: R1, R2, …, Rm.
Application Interface for Ak:
IA = (k, k, Hk()) k: virtual processor speed.
k: jitter tolerance.
• Hk(Rℓ): Ak’s resource-hold time of Rℓ.
Each application Ak comprised of sporadic tasks system (Ak).
Background – Prior Work– Our Results– Summary
kMaximum continuous
interval that Ak may lock Rℓ.
Our Results: Resource-Sharing Framework 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
IA = (k, k, Hk()) BROE Server Rules:1. Initialize to “normal” replenishment values:
• Period:• Maximum Budget: • Deadline:
kFor all intervals of size t > k, execution over interval
should be at least (t- k ) k
k
Pk =k
2(1-k)Ek =
kk
2(1-k)Dk = + tcur
k
2(1-k)Task system (Ak) scheduled within server
allocation by Ak’s local scheduler.Earlier-deadline applications are executing.
Background – Prior Work– Our Results– Summary
Our Results: Resource-Sharing FrameworkBROE Server Rules:1. Initialize to “normal” replenishment values.
2. If server is executing, budget is decremented at rate 1.
Budgettime0
Ek =-1, if Ak executing,
0, otherwise.d
dt
IA = (k, k, Hk()) k
Background – Prior Work– Our Results– Summary
Our Results: Resource-Sharing FrameworkBROE Server Rules:1. Initialize to “normal” replenishment values.
2. If server is executing, budget is decremented at rate 1.
3. If task of (Ak) requests resource Rℓ when Ek < Hk(Rℓ ), then defer execution and update replenishment time & next deadline:
Task requests RTask requests Rℓℓ, ,
but Ebut Ekk < H < Hkk(R(Rℓℓ))
Access to RAccess to Rℓℓ is is
granted heregranted herekExecution over interval > (t- k)k
IA = (k, k, Hk()) k
Background – Prior Work– Our Results– Summary
Our Results: Formal Properties Composability Test:
Bk: largest Hi(Rℓ) value that can block Ak.
Theorem: Applications A1, A2, …, Aq composable on a unit-speed processor if for all k {1,…, q}:
j + 1Bk
PkPj Pk
Background – Prior Work– Our Results– Summary
Our Results: Formal Properties Composability Test:
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.
Theorem: Applications A1, A2, …, Aq composable on a unit-speed processor if for all k {1,…, q}:
j + 1Bk
PkPj Pk
Background – Prior Work– Our Results– Summary
k
Our Results: Resource-Hold Times 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 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 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
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.
