Title : CPU Broker (DSRT Extension)

1. Title : CPU Broker(DSRT Extension) Kihun Kim University of Illinois at Urbana-Champaign

2. Design Goal of CPU Broker • Separation of CPU reservation from scheduling. • Prevent the scheduler from being interrupted by reservation requests, giving a RT process the contracted QoS. • Control CPU reservation from the remote site. • Furthermore, centralized reservation of the distributed system.

3. Design Goal of CPU Broker(Cont.) • Integrate advance reservation with immediate reservation. • Immediate reservation • Admission decision based on the resource availability at hand. • Advance reservation • reserve the resource for the future usage. • Time parameter (start time, duration) required.

4. RT process Client Broker CPU Monitor Reservation Modification Allocation Release Brokerage Services Probe Allocation CPU Scheduler CPU Broker Adaptation System Architecture

5. Brokerage Services • Parameters • QoS : [period, execution time] • Time : [start time, duration]  Missing start time  current time(immediate reservation)  Missing duration  default duration • Options for reservation & release

6. Configurable Reservation Option • Alternative QoS and time parameter. • When admission control based on (QoS, start time, duration) parameters fails, CPU broker performs the second test with the modified parameters, (Reduced QoS, start time, duration). (QoS, start time, reduced duration). (QoS, the next possible start time, duration).

7. Configurable Release Options • Early termination : • Auto release : free the reserved resource. • Explicit release : keep the reserved resource until the client requests the resource release. • Delayed termination : 1) auto extension : extend the reserved time by the default duration. 2) forced release : release the reserved resource immediately.

8. 30/20 10 20 10 0 50 40 30 T T+a T+2a T+3a T+4a Admission Control Algorithm • Timely adaptive state tree(TAST). • Track the resource status from the current time to the future. • Leaf node : the minimum Reservation unit time. • Internal node : a time block. (Block_load / Max_load)  Block_load : constant load.  Max_load : maximum load.

9. Admission Control Algorithm(cont.) • Each processor is bound with one TAST. • Scan a TAST to check resource availability in between the time interval with the requested QoS. • If found a free processor, then update the TAST to reflect the accepted QoS. • If not found any free processor, perform admission test with the modified (QoS, time) parameter.

10. TAST : Example (1)

11. TAST : Example (2)

12. CPU Broker Architecture(Reservation) Admission Controller (1)Reserve (QoS, Time, option) (4) Processor ID Event Handler (2) Client (5) (QoS, Time,option) (7) (8) Ticket (6) Ticket (3) Search idling processor(QoS, Time) Reservation Information Table TASTs Processor (0-N)

13. CPU Broker Architecture(Allocation) Event Handler (3) QoS Allocation Client Scheduler (1) Allocation (QoS,Ticket) (2) User authentication (QoS, Ticket) Reservation Information Table (3) Reservation state change

14. Reservation Information Table • User ID • Reserve-ID : reservation ticket • Event indices : start index and end index in the TAST • Reserve : reserved QoS • Schedule : scheduled QoS

15. Reservation Information Table : Example • User 1 (kikim) • Reserved 32 % CPU. • Ticket : 01752 • User2 (klara) • Reserved 20 % CPU. • Ticket : 01753 • RT processes • p1(8157) uses 15 % • p2(8140) uses 17 % • p3(8000) uses 15 %

16. Experiment - (1) Response time comparison for admission control tests between immediate reservation and advance reservation

17. Response time of reservation • requests in DSRT (b) Response time of reservation requests in Broker - DSRT Experiment - (2)

18. Contribution • Fast and constant response time of all brokerage requests. • An integrated reservation scheme. • Flexible negotiation functionalities for resource reservation.