Quality of Service su Linux: Passato Presente e Futuro Luca Abeni - - PowerPoint PPT Presentation

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 Ji,j Every job Ji,j: Arrives at time ri,j (when the task unblocks) Executes for a time ci,j Finishes at time fi,j (when the task blocks) Should finish within a soft deadline di,j

fi,j c i,j ri,j di,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

Scheduler

Event Delivery Dispatch Event Time

Latency

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 Qs Capacity q: decreased when the task executes

q = 0 ⇒ ds = ds + T s

On job arrival, check if a new scheduling deadline must be assigned

r > d − q T s

Qs ⇒ ds = r + T s; q = Qs

• therwise, leave ds 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

τ 1 Q = 1ms T = 4ms

1 1

T = 4ms

2 2

Q = 3ms τ 2 t t

1 2

The “Short Period” problem

Q = 10.5 Q T = 10.5 T

τ τ

Q T

1 1 2 2 1 1 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, CBS Greedy Task, Reclaiming Short Period, CBS Short Period, HGRUB

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 > 100ms Preemptable Linux: 1ms < L < 10ms 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 (Qs, T s) to device drivers... Various possibilities: Client / Server model: compute (Qs, 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 (Qs, 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