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

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

H-SFQ CPU/Packet Scheduler

Requirements for New CPU Scheduler 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? Complaint: The video refreshes too slow!

Requirements for New CPU Scheduler 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? Complaint: I can’t input anything into my editor!

Requirements for New CPU Scheduler Problem Analysis 1.A conventional CPU scheduler can not adapt multiple classes of applications simultaneously. 2.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.

H-SFQ CPU Scheduler —— A Sample Hierarchy

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

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.

SFQ CPU Scheduler —— Algorithm Description(2)

SFQ CPU Scheduler —— Properties SFQ achieves fair allocation of CPU regardless of variation in available processing bandwidth 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 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 SFQ provides bounds on maximum delay incurred and minimum throughput achieved by the threads

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

H-SFQ CPU Scheduler —— Evaluation(1)

H-SFQ CPU Scheduler —— Evaluation(2)

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

Cello Disk Scheduler

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

Cello Disk Scheduler —— Architectural Principles

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

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

Cello Disk Scheduler —— Implementation Ideas(2) 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 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,

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

Cello Disk Scheduler —— Evaluation(1)

Cello Disk Scheduler —— Evaluation(2)

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

Lazy Receiver Processing (LRP)

Conventional Linux Network Architecture for Receiving Packets

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

LRP Architecture

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

Comparision of Two Architectures(1) Conventional Linux LRP LRP Demultiplexing Position Sockets Queue NI Channel The initial Position of Dropping Packets Sockets Queue NI Channel Demultiplexing Income Packets What is the advantage of early demultiplexing packets in LRP? Traffic separation and effective load shedding

Comparision of Two Architectures(2) Conventional Linux LRP LRP Time when the packet is passed from NI when the application process call receive() TCP/IP Protocol Processing Postion Hard/Soft interrupt handler driven as kernel level invoked in receive() as user level Who charge for Protocol Processing Time The process when a interrupt comes The process who will consume the packet Packets Processing What is the advantage of delayed packet processing in LRP? Support stability and fairness under overload and correct CPU time accounting

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

Related Works

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

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.

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.

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 , October 1996.A Hierarchical CPU Scheduler for Multimedia Operating Systems, [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 , August 1996.Start-time Fair Queuing: A Scheduling Algorithm for Integrated Services Packet Switching Networks, [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.Cello: A Disk Scheduling Framework for Next Generation Operating Systems, [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 , October 1996Lazy Receiver Processing (LRP): A Network Subsystem Architecture for Server Systems, [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 , November November Application Performance in the QLinux Multimedia Operating System, [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 [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 , Taipei, Taiwan, May 30-June [8] John Regehr and John A. Stankovic, Operating System Support for Multimedia: The Programming Model Matthers