Transcript The Partitioned Scheduling of Sporadic Tasks on

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

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
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 realApplication 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:
A
Virtual Processor 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
A
Virtual Processor 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
A
Virtual Processor A
Each application
independently developed
& validated.
Application A:
1
2
Local
Scheduler
3
Global
Scheduler
Virtual Processor B
Application B:
’1
’2
CPU
Local
Scheduler
IB
Application-Level
Schedulability Test
Background – Prior Work– Our Results– Summary
Motivation: Real-Time Open
Environments I
A
Virtual Processor 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
A
Virtual Processor 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
A
Application Server A
resources.
Application A:
1
2
Implication: Applications
not completely independent.
Local
Scheduler
3
Global
Scheduler
Application Server B
Application B:
’1
’2
R1 R2 … Rm
CPU
Local
Scheduler
IB
Background – Prior Work– Our Results– Summary
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
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
Our Results: System Model



Applications: A1, A2, …, Aq.
Global Resources: R1, R2, …, Rm.
Application Interface for Ak:
IAk= (k, 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ℓ.

Each application Ak comprised of sporadic
tasks system (Ak).
Background – Prior Work– Our Results– Summary
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
BROE Server Rules:
IAk= (k, 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, k, Hk())
Initialize to “normal” replenishment values.
If server is executing, budget is decremented at
rate 1.
-1, if Ak executing,
d
dt
Ek =
0,
otherwise.
Budget
0
time
Background – Prior Work– Our Results– Summary
Our Results: Resource-Sharing
Framework
BROE Server Rules:
1.
2.
3.
IAk= (k, 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

Composability Test:
Theorem: Applications A1, A2, …, Aq composable on
a unit-speed processor if for all k {1,…, q}:
 j +
Pj  Pk
Bk
Pk
1
Bk: largest Hi(Rℓ) value that can block Ak.
Background – Prior Work– Our Results– Summary
Our Results: Formal Properties

Composability Test:
Theorem: Applications A1, A2, …, Aq composable on
a unit-speed processor if for all k {1,…, q}:
 j +
Pj  Pk

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 IAk (k, k, Hk()) when using EDF + SRP.
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.
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.
Thank You!
Questions?
[email protected]