Quality of Service su Linux: Passato Presente e Futuro Luca Abeni luca.abeni@unitn.it Universit` a di Trento Quality of Service su Linux:Passato Presente e Futuro – p. 1
Quality of Service Time Sensitive applications → Implicit temporal constraints: CD Burner Multimedia Streaming client Video Conference Different Time-Sensitive applications can run simultaneously in the same PC A Time-Sensitive application should be able to run on many different systems Temporal constraints must be modelled through QoS metrics Quality of Service su Linux:Passato Presente e Futuro – p. 2
QoS of Linux Tasks Problem: how to map QoS parameters on Linux processes/threads? Task τ i : stream of Jobs J i,j Every job J i,j : Arrives at time r i,j (when the task unblocks) Executes for a time c i,j Finishes at time f i,j (when the task blocks) Should finish within a soft deadline d i,j c i,j d i,j f i,j r i,j Quality of Service su Linux:Passato Presente e Futuro – p. 3
Need for an “EndCycle” API Simple mapping between Linux processes/threads and RT tasks / jobs: Task unblocks → job arrival Task blocks → job termination This works well for scheduling... ...But is not good for measuring the QoS! For measuring the QoS experienced by a task: The beginning and termination of a job must be explicitly signalled Some kind of “endcycle()” call is needed to indicate that a job terminates → the termination time can be compared with the job deadline Quality of Service su Linux:Passato Presente e Futuro – p. 4
Requirements on the OS Kernel Goal: finish each job within its deadline Can be achieved through a proper scheduling Reservation-based scheduling: guarantee a time Q every T to task τ i Scheduling in practice: divergence between theoretical and actual schedule Due to latencies introduced by the system A latency can be modelled as a blocking time... ...But we want to reduce it to the minimum Quality of Service su Linux:Passato Presente e Futuro – p. 5
Kernel Support Scheduler → triggered by internal (IPC) or external (IRQ) events Time between the triggering event and dispatch: Event generation Event delivery (example: interrupts may be disabled) Scheduler invocation (non-preemptable sections) Scheduling/Dispatch time Latency Event Time Event Delivery Dispatch Scheduler Commercial RT OSs → reduce this latency Quality of Service su Linux:Passato Presente e Futuro – p. 6
Resource Reservations Resource Reservations are an effective way for implementing temporal protection Every task is allowed to use a resource for an amount of time Q every period T Two fundamental mechanisms: accounting and enforcement CPU scheduling → CPU Reservations (implemented in Resource Kernels) Traditional implementations → aperiodic servers Deferrable Server... Quality of Service su Linux:Passato Presente e Futuro – p. 7
Broken Temporal Protection Tasks are always backlogged Task 1 is inactive when the reserve is replenished Broken Isolation!!! Quality of Service su Linux:Passato Presente e Futuro – p. 8
Our Solution Scheduling Algorithm: Constant Bandwidth Server EDF scheduler → tasks are scheduled according to scheduling deadlines Scheduling deadlines are assigned by servers Server: Server Period T s , Maximum Budget Q s Capacity q : decreased when the task executes q = 0 ⇒ d s = d s + T s On job arrival, check if a new scheduling deadline must be assigned Q s ⇒ d s = r + T s ; q = Q s r > d − q T s otherwise, leave d s and q to current values Can cope with aperiodic arrivals Quality of Service su Linux:Passato Presente e Futuro – p. 9
The CBS - An Example CBS with aperiodic arrivals Thanks to the deadline assignment rule, temporal isolation is preserved The CBS is automagically synchronised with periodic tasks Quality of Service su Linux:Passato Presente e Futuro – p. 10
Resource Reservations for non RT Tasks Can we use the same reservation algorithm for both real-time and non real-time tasks? The CBS works very well for real-time tasks... ...But has problems when serving non real-time tasks The “Greedy Task” problem The “Short Period” problem Q = 1ms τ 1 1 T = 4ms Q τ 1 1 1 t T 1 1 Q = 3ms τ 2 2 Q = 10.5 Q τ T = 4ms 2 1 2 2 T = 10.5 T t 2 1 2 Quality of Service su Linux:Passato Presente e Futuro – p. 11
Solving the two Problems The Greedy Task and Short Period problems are not critical for real-time tasks... For a real-time task the only important thing is to respect a deadline The QoS of a time-sensitive task is not affected if the task finishes earlier than expected ...But they affect the performance of non real-time tasks Fairness matters! Solution: HGRUB Reclaiming mechanism (GRUB) Modifies the accounting mechanism Hard reservation behaviour Modifies the enforcement mechanism Quality of Service su Linux:Passato Presente e Futuro – p. 12
HGRUB in Action Greedy Task, Reclaiming Greedy Task, CBS Short Period, HGRUB Short Period, CBS Quality of Service su Linux:Passato Presente e Futuro – p. 13
Kernel Latencies Linux: monolithic kernel → maximum latency L = size of the largest kernel section Traditional non-preemptable kernel: execution in kernel mode cannot be preempted Preemptable kernel: execution in kernel mode can be preempted when no spinlocks are held Timer resolution is not an issue anymore (since kernel 2.6.21) Spinlocks → non-preemptable sections Threaded interrupt handlers (and bottom halves) Transform spinlocks in mutexes Priority Inheritance All done in Ingo Molnar’s RT patch Quality of Service su Linux:Passato Presente e Futuro – p. 14
Kernel Latencies - Some Values Experimental setup: Intel Celeron (@ about 1.2GHz) Periodic RT task (period T ) Background NRT load, stressing the kernel Measure the interactivation time T ′ ; L = T ′ − T Non-preemptable kernel: L > 100 ms Preemptable Linux: 1 ms < L < 10 ms RT Patch: L < 40 µs Slower processor (AMD K3 @ about 400MHz): about 100 µs It is possible to do Hard Real-Time in User Space !!! Quality of Service su Linux:Passato Presente e Futuro – p. 15
Scheduling the Device Drivers The CPU is not the only resource needed by RT tasks! There are resource schedulers for Network, Disk, etc... Problem: cooperative-scheduling → the resource must be allocated to an application when there is enough CPU time for scheduling the application / the drivers... With the RT patch, interrupt handlers are threads ⇒ it is possible to schedule them We believe that scheduling device drivers can: Help cooperative-scheduling Account the time spent in interrupt handling Control the interference from device drivers on RT applications Quality of Service su Linux:Passato Presente e Futuro – p. 16
Allocating CPU to Interrupt Handlers Which scheduling algorithm / parameters must be used for ISRs and bottom halves? Problem: assign ( Q s , T s ) to device drivers... Various possibilities: Client / Server model: compute ( Q s , T s ) based on the QoS requested by clients (applications using the driver) Inheritance: when a QoS-aware application uses a driver, the driver’s threads inherit the application’s reservations Feedback-based approach: use the QoS experienced by applications using the driver to dynamically adjust the driver’s reservation Quality of Service su Linux:Passato Presente e Futuro – p. 17
Resource Reservations vs Fair Scheduling Linux is going to include a fair scheduler (CFS) CFS is already included in the RT patch Sometimes, people do not really want real Resource Reservations Maybe the ( Q s , T s ) model is overkilling? (sometimes, people just want “give me x % of the CPU”) T s is often seen as an allocation granularity , not related to tasks’ deadlines... ...So, maybe the CFS model can be used? (It surely is simpler) What are the mathematical properties of CFS? What’s the relation between CFS and CBS / GRUB / HGRUB? Quality of Service su Linux:Passato Presente e Futuro – p. 18
Other Co-Scheduling Problems Typical application based on the Client/Server paradigm: the X Server Different scheduling levels: CPU scheduling of the client applications CPU scheduling of the X server Requests scheduling in X Problem: how to assign the proper CPU reservations to X and to the clients, and how to schedule the client requests in X? We developed a tracer for X, and we are implementing reservations in the X scheduler Reserving CPU to X: see IRQ scheduling... Quality of Service su Linux:Passato Presente e Futuro – p. 19
Recommend
More recommend
