Application Performance in the QLinux Multimedia Operating System

1. Application Performance in the QLinux Multimedia Operating System Jun Wang

2. Overview • H-SFQ CPU/Packet Scheduler • Cello Disk Scheduler • Lazy Receiver Processing (LRP) • Related Works • Open Discussions

3. H-SFQ CPU/Packet Scheduler

4. Requirements for New CPU Scheduler Complaint:The video refreshes too slow! Example 1 Consider a MPEG decoder and some conventional processes running together. The CPU scheduler is the standard time sharing scheduler. The MPEG decoder has a soft real-time demand which is 25 frames per seconds. When the number of conventional processes increases, what is the problem?

5. Requirements for New CPU Scheduler Complaint: I can’t input anything into my editor! Example 2 Consider some conventional processes and some hard real-time processes such as control system of aircraft running together in a real-time OS. The CPU scheduler is Earliest Deadline First (EDF). When the number of hard real-time processes increases, what is the problem?

6. Requirements for New CPU Scheduler • Problem Analysis • A conventional CPU scheduler can not adapt multiple classes of applications simultaneously. • A conventional CPU scheduler can not isolate different classes of applications so that increasing the load of one class of applications does not influence other classes of applications.

7. H-SFQ CPU Scheduler—— A Sample Hierarchy

8. H-SFQ CPU Scheduler—— Features • Multiple level scheduling structure ♠class-independent scheduler for non-leaf node & class-specific scheduler for leaf node • Support for multiple service classes ♠solving the simultaneous occurrence problem • Predictable resource allocation ♠solving the isolation problem • Proper accounting of resource usage ♠accounting of CPU usage by virtual time

9. SFQ CPU Scheduler—— Algorithm Description(1) Example: Consider two threads A and B with weights 1 and 2,respectively,which become runnable at time t=0. Thread A will run 80ms to finish, and Thread B will run 110ms to finish.But both of them will block at some time. Let the scheduling quantum for each thread be 10ms.

10. SFQ CPU Scheduler—— Algorithm Description(2)

11. SFQ CPU Scheduler—— Properties • SFQ achieves fair allocation of CPU regardless of variation in available processing bandwidth • SFQ does not require the length of the quantum to be known a priori • SFQ provides bounds on maximum delay incurred and minimum throughput achieved by the threads

12. H-SFQ CPU Scheduler—— implementation Weight Start-tag Finish-tag

13. H-SFQ CPU Scheduler—— Evaluation(1)

14. H-SFQ CPU Scheduler—— Evaluation(2)

15. Open Discussions— Section One • How to convert different user requirements into weights in H-SFQ? • HLS: another hierarchical framework for soft Real-time schedulers ♣Multiple kinds of schedulers in non-leaf nodes ♣Support both relative allocations and absolute allocations

16. Cello Disk Scheduler

17. Requirements for New Disk Scheduler Conventional Disk schedulers experience the same simultaneous occurrence problems and isolation problem as the conventional CPU schedulers

18. Cello Disk Scheduler—— Architectural Principles

19. Cello Disk Scheduler—— Features • Multiple level scheduling structure • Class-independent scheduler combines weight and disk service time into its decision of scheduling. • Class-specific scheduler steal the slack time of soft real-time requests for interactive requests as much as possible

20. Cello Disk Scheduler—— Implementation Ideas(1) Example: There are 3 classes disk requests with equal weights in the system, one is soft real-time class with 20ms deadline for every request and 6ms service time, one is interactive class with 3 ms service time, the last is throughput-intensive class. The following figure shows the contents of pending queues and scheduled queue at the beginning of a certain time interval which is 45ms. soft real-time r3 r2 r1 interactive Scheduled Queue i3 i2 i1 throughput-intensive t1

21. Cello Disk Scheduler—— Implementation Ideas(2) Switching from one class to another class when one of three conditions is met: ᆞthe pending queue for a class is empty ᆞthe sum of requests outweigh the class’s proportion ᆞthe sum of requests outweigh the current time interval, soft real-time r3 r2 interactive Scheduled Queue i3 i2 i1 r1 throughput-intensive t1 soft real-time r3 interactive Scheduled Queue i3 i2 i1 r2 r1 throughput-intensive t1

22. Slack time of a request i: equal to Max(0,li-ei). Li: the latest time by which the disk must begin servicing this request Ei: the earliest time at which the disk may begin servicing a request Cello Disk Scheduler—— Implementation Ideas(3) Different class-specific schedulers have different insert strategies. ᆞReal-time: EDF+SCAN ᆞInteractive: Steal slack time ᆞThroughput-intensive: insert towards the tail soft real-time r3 interactive Scheduled Queue i3 i2 i1 i3 r2 i2 i1 r1 throughput-intensive t1 Unused disk bandwidth for interactive class can be assigned to other classes according to their weight. soft real-time r3 interactive Scheduled Queue t1 r3 i3 r2 i2 i1 r1 throughput-intensive t1

23. Cello Disk Scheduler—— Evaluation(1)

24. Cello Disk Scheduler—— Evaluation(2)

25. Open Discussions— Section Two • Overload of recomputing slack time after insertion of each request. Possible reductions?

26. Lazy Receiver Processing (LRP)

27. Conventional Linux Network Architecture for Receiving Packets

28. Problem Analysis • Eager receiver processing ♠starvingapplications problem • Lack of effective load shedding ♠livestock problem • Lack of traffic separation ♠applications isolation problem • Inappropriate resource accounting ♠Account CPU time unfair

29. LRP Architecture

30. Features of LRP • Lazy receiver processing • Dropping packets as soon as possible • Different NI channels for different sockets • accurate resource accounting

31. What is the advantage of early demultiplexing packets in LRP? Traffic separation and effective load shedding Comparision of Two Architectures(1) Demultiplexing Income Packets

32. What is the advantage of delayed packet processing in LRP? Support stability and fairness under overload and correct CPU time accounting Comparision of Two Architectures(2) Packets Processing

33. Open Discussions—Section Three • Accounting CPU time ♣Virtual time How to make up the stolen time for a process? ♣Lazy receiver processing

34. Related Works

35. QLinux ♠ Resource Reservation for different classes of applications by multiple level schedulers ♠ Reallocating dynamically unused resources

36. ControlWare & QLinux A Problem with QLinux : how to map QoS directly to the appropriate weight? QLinux can only tell that you can get some performance guarantee with a certain weight. But if you want to get some certain QoS, what is the appropriate weight assigned to you? A possible solution: using some feedback mechanism like ControlWare to adjust the weights until finding the appropriate weight for a certain QoS.

37. QuO & QLinux QuO solves how to transmit the QoS information between a client and an object based on the QoS parameters of underlying OS and network. So QLinux can serve very well for QuO.

38. References [1] P. Goyal and X. Guo and H.M. Vin, A Hierarchical CPU Scheduler for Multimedia Operating Systems, Proceedings of 2nd Symposium on Operating System Design and Implementation (OSDI'96), Seattle, WA, pages 107-122, October 1996. [2] P. Goyal and H. M. Vin and H. Cheng, Start-time Fair Queuing: A Scheduling Algorithm for Integrated Services Packet Switching Networks,Proceedings of ACM SIGCOMM'96, pages 157-168, August 1996. [3] P Shenoy and H M. Vin, Cello: A Disk Scheduling Framework for Next Generation Operating Systems,Proceedings of ACM SIGMETRICS Conference, Madison, WI, pages 44-55, June 1998. [4] P. Druschel and G. Banga, Lazy Receiver Processing (LRP): A Network Subsystem Architecture for Server Systems,Proceedings of the 2nd Symposium on Operating System Design and Implementation (OSDI'96), Seattle, WA, Pages 261-275, October 1996 [5] Vijay Sundaram, Abhishek Chandra, Pawan Goyal and Prashant Shenoy, Application Performance in the QLinux Multimedia Operating System ,Proceedings of the Eighth ACM Conference on Multimedia, Los Angeles, CA, pages 127-136, November 2000. November 2000. [6] John Regehr and John A. Stankovic, HLS:A Framework for Composing Soft Real-Time Schedulers, Proceedings of the 22nd IEEE Real-Time Systems Symposium (RTSS 2001), pages 3-14, London, UK, December 3-6 2001. [7] John Regehr and John A. Stankovic, Augmented CPU Reservations: Towards Predictable Execution on General-Purpose Operating Systems, Proceedings of the Seventh IEEE Real-Time Technology and Applications Symposium (RTAS 2001), pages 141-148, Taipei, Taiwan, May 30-June 1 2001 [8] John Regehr and John A. Stankovic, Operating System Support for Multimedia: The Programming Model Matthers