Quality of Service su Linux: Passato Presente e Futuro

Size: px

Start display at page:

Download "Quality of Service su Linux: Passato Presente e Futuro"

Abner Copeland
8 years ago
Views:

1 Quality of Service su Linux: Passato Presente e Futuro Luca Abeni luca.abeni@unitn.it Università di Trento Quality of Service su Linux:Passato Presente e Futuro p. 1

2 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

the same PC A Time-Sensitive application should be able to run on many different systems Temporal

3 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 r i,j f i,j d i,j Quality of Service su Linux:Passato Presente e Futuro p. 3

unblocks) Executes for a time c i,j Finishes at time f i,j (when the task blocks) Should

4 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

For measuring the QoS experienced by a task: The beginning and termination of a job must be explicitly signalled Some kind of

5 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

divergence between theoretical and actual schedule Due to latencies introduced by the system A latency can be

6 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 Event Time Event Delivery Latency Scheduler Dispatch Commercial RT OSs reduce this latency Quality of Service su Linux:Passato Presente e Futuro p. 6

Scheduler invocation (non-preemptable sections) Scheduling/Dispatch time Event Time Event Delivery

7 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

accounting and enforcement CPU scheduling CPU Reservations (implemented in Resource Kernels) Traditional

8 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

9 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 r > d q T s Q s d s = r + T s ;q = Q 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

executes q = 0 d s = d s + T s On job arrival, check if a new scheduling deadline must be assigned r > d q T s Q s d s = r + T s ;q

10 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

preserved The CBS is automagically synchronised with

11 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 τ 1 Q = 1ms 1 T 1= 4ms t1 τ 1 Q T 1 1 τ 2 Q = 3ms 2 T 2= 4ms t2 τ 2 Q = 10.5 Q 2 T = 10.5 T Quality of Service su Linux:Passato Presente e Futuro p. 11

.....but has problems when serving non real-time tasks The Greedy Task problem The Short Period problem τ 1

12 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

finishes earlier than expected...but they affect the performance of non real-time tasks Fairness matters!

13 HGRUB in Action Greedy Task, CBS Greedy Task, Reclaiming Short Period, CBS Short Period, HGRUB Quality of Service su Linux:Passato Presente e Futuro p. 13

14 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 ) 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

resolution is not an issue anymore (since kernel 2.6.

15 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 > 100ms Preemptable Linux: 1ms < L < 10ms RT Patch: L < 40µs Slower processor (AMD 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

; L = T T Non-preemptable kernel: L > 100ms Preemptable Linux: 1ms < L < 10ms RT Patch: L < 40µs Slower

16 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

17 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

.. Various possibilities: Client / Server model: compute (Q s,t s ) based on the QoS requested by clients (applications using the driver) Inheritance:

18 esource 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

(sometimes, people just want give me x% of the CPU ) T s is often seen as an allocation granularity, not related to tasks deadlines.

19 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

reservations to X and to the clients, and how to schedule the client requests in X?

Using EDF in Linux: SCHED DEADLINE. Luca Abeni luca.abeni@unitn.it

Using EDF in Linux: SCHED DEADLINE. Luca Abeni luca.abeni@unitn.it Using EDF in Linux: Luca Abeni luca.abeni@unitn.it Using Fixed Priorities in Linux SCHED FIFO and SCHED RR use fixed priorities They can be used for real-time tasks, to implement RM and DM Real-time tasks