The Design of an EDFScheduled ResourceSharing Open Environment

1
The Design of an EDF-Scheduled Resource-Sharing
Open Environment

• Nathan Fisher
• Wayne State University

Marko Bertogna Scuola Superiore SantaAnna 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.

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
?2
Real-Time Tasks
?3
Application B
?1
?2
Background Prior Work Our Results Summary
5
Motivation Traditional Real-Time System Design
Schedulability Test
Application A
Task Specifications
?1
?2
Scheduler
?3
CPU
Application B
?1
?2
Background Prior Work Our Results Summary
6
Motivation Traditional Real-Time System Design
Assumption All tasks of all real-time
applications are known at system-validation time.
Application A
?1
?2
Scheduler
?3
CPU
Application B
?1
?2
Each task submits jobs directly to CPU scheduler.
Background Prior Work Our Results Summary
7
Motivation Traditional Real-Time System Design

• Violation of System Design Principles
• Encapsulation Abstraction.
• Modularity Hierarchical Design.
• Fault-containment.

• Drawbacks
• All tasks in the system need to be validated
  together and known to system designer, a priori.
• Monolithic system design.
• Each application on shared platform must use same
  scheduling algorithm.
• Temporally-bad behavior of one task may affect
  other tasks.

Solution?
Background Prior Work Our Results Summary
8
Motivation Real-Time Open Environments

• Application Interface
• VP Speed.
• Jitter tolerance.

Application A
?1
?2
Scheduler
CPU
?3
Global
Application B
?1
?2
Background Prior Work Our Results Summary
9
Motivation Real-Time Open Environments
Application-Level Schedulability Test
Local Scheduler
Scheduler
CPU
Global
Local Scheduler
Background Prior Work Our Results Summary
10
Motivation Real-Time Open Environments
Each application independently developed
validated.
Local Scheduler
Scheduler
CPU
Global
Local Scheduler
Application-Level Schedulability Test
Background Prior Work Our Results Summary
11
Motivation Real-Time Open Environments
Composability Test
Local Scheduler
Scheduler
CPU
Global
Local Scheduler
Background Prior Work Our Results Summary
12
Motivation Real-Time Open Environments
Local Scheduler
Scheduler
CPU
Global
Local Scheduler
Background Prior Work Our Results Summary
13
Motivation Real-Time Open Environments

• Advantages
• Applications temporal constraints may be
  validated independently and need not be known a
  priori.
• Component-based design.
• Service-oriented design.
• Each application on shared platform may use
  different scheduling algorithm.
• 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
Challenge Tasks may access shared global
resources.
Local Scheduler
Implication Applications not completely
independent.
Scheduler
CPU

R1
R2
Rm
Global
Local Scheduler
Background Prior Work Our Results Summary
15
Prior Work Real-Time Open Environments
Deng Liu, RTSS 1997

• 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
16
Prior Work Real-Time Open Environments
Deng Liu, RTSS 1997

• Second Generation Open Environments
• Recent Work
• Davis Burns RTSS 2006.
• Behnam et al. RTSS-WiP 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
17
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(Rl) Aks resource-hold time of Rl.
• Each application Ak comprised of sporadic tasks
  system ?(Ak).

Maximum continuous interval that Ak may lock Rl.
k
Background Prior Work Our Results Summary
18
Our Results System Model Sporadic Task Model
Worst case Execution Requirement
Period
Relative Deadline
?i (ei,di,pi)
time
Task Systems for Ak ?(Ak) ?1,, ?n
19
Our Results System Model

• Applications A1, A2, , Aq.
• Global Resources R1, R2, , Rm.
• Each application comprised of sporadic tasks.
• Application Interface for Ak
• IA (?k, ?k, Hk(?))
• ?k virtual processor speed.
• ?k jitter tolerance.
• Hk(Rl) Aks resource-hold time of Rl.

k
20
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
21
Our Results Resource-Sharing Framework
IA (?k, ?k, Hk(?))

• BROE Server Rules
• Initialize to normal replenishment values
• Period
• Maximum Budget
• Deadline

k
Task system ?(Ak) scheduled within server
allocation by Aks local scheduler.
Earlier-deadline applications are executing.
For all intervals of size t gt ?k, execution over
interval should be at least (t- ?k ) ?k
Background Prior Work Our Results Summary
22
Our Results Resource-Sharing Framework
IA (?k, ?k, Hk(?))

• BROE Server Rules
• Initialize to normal replenishment values.
• If server is executing, budget is decremented at
  rate 1.

k
Budget
0
time
Background Prior Work Our Results Summary
23
Our Results Resource-Sharing Framework
IA (?k, ?k, Hk(?))

• BROE Server Rules
• Initialize to normal replenishment values.
• If server is executing, budget is decremented at
  rate 1.
• If task of ?(Ak) requests resource Rl when
  Ek lt Hk(Rl ), then defer execution and update
  replenishment time next deadline

k
Access to Rl is granted here
Task requests Rl, but Ek lt Hk(Rl)
Execution over interval gt (t- ?k)?k
Background Prior Work Our Results Summary
24
Our Results Formal Properties

• Composability Test

Theorem Applications A1, A2, , Aq composable
on a unit-speed processor if for all k? 1,, q
? ?j ? 1
Pj ? Pk
Bk largest Hi(Rl) value that can block Ak.
Background Prior Work Our Results Summary
25
Our Results Formal Properties

• Composability Test
• Local-Scheduler Optimality

Theorem Applications A1, A2, , Aq composable
on a unit-speed processor if for all k? 1,, q
? ?j ? 1
Pj ? Pk

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

k
Background Prior Work Our Results Summary
26
Our Results Resource-Hold Times

• How do you determine Hk(Rl)?
• If ?(Ak) feasible when non-preemptively executing
  Rl on VP, execute non-preemptively on BROE server.

Hk(Rl) equals duration of longest critical
section of ?(Ak) on Rl.
Background Prior Work Our Results Summary
27
Our Results Resource-Hold Times

• How do you determine Hk(Rl)?
• If ?(Ak) feasible when non-preemptively executing
  Rl on VP, execute non-preemptively on BROE
  server.
• If ?(Ak) infeasible on VP using EDFSRP, then by
  optimality theorem, ?(Ak) cannot be scheduled
  on server of speed ?k.
• If neither above hold devise local scheduling
  technique for minimizing application resource
  hold time.

Previous paper RTAS 2007 describes Hk(Rl)
minimization for EDFSRP.
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
  applications 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_at_cs.wayne.edu