Chapter 6. Quality of Service Components

One of the goals of the OCERA QoS component is to provide a predictable Quality of Service level to both kernel level (RTLinux) and user level (regular Linux tasks). A correct resource allocation is fundamental to guarantee a predictable QoS, and in order to precisely allocating resources two requirements must be fulfilled:

1. Tasks must be scheduled with a low latency;

2. A proper scheduling algorithm must be used to guarantee real-time performance to tasks.

At the kernel level, RTLinux provides low latencies, and the extended scheduler developed by UPVLC can be used to guarantee the correct CPU allocation.

At the user level, a proper resource allocation can be obtained by combining techniques analysed in Deliverable D1.1 (the low-latency or kernel preemptability patches) and novel scheduling strategies. In a traditional RTLinux system, the Linux kernel is scheduled in background respect to all the real-time tasks, and as a result user-level tasks experience big latencies and non predictable delays. This problem can be solved by scheduling Linux as a real-time task, and not as a background one.

Since the Linux kernel is scheduled by the low-level flexible scheduler implemented in RTLinux, the guarantees provided by the two schedulers must be combined in a hierarchical fashion to control the QoS delivered to the application.

Resource Reservation techniques (described in Deliverable D3.3) are particularly useful for hierarchically combining the two schedulers, since they permit to reserve a fraction of the CPU time to the scheduled entities. Hence, this combination allows to reserve a fraction Bl of the total CPU time to the Linux kernel and then a fraction Bi of the Linux time to each user-level task. An approximate guarantees can intuitively be provided by multiplying the two fractions, and an user-level task is reserved a fraction of the total CPU time equal to about Bi * Bl [1].

Hence, the QoS component will be based on:

1. Preemptability or low-latency patches that permit to decrease the scheduling latency experienced by user level applications;

2. A high-resolution timers patch that increases the kernel timing accuracy;

3. A loadable kernel module that permits to schedule user-level tasks with a proper algorithm;

4. Mathematical tools that permit to combine the kernel-level and user-level guarantees.

5. A QoS Manager, which uses the patches and modules described above to properly allocate CPU to each application.

As a result, the QoS component will use features provided by the Real-Time Scheduling component, and will depend on it to implement hierarchical scheduling. Note, however, that the QoS component can be used also if the Real-Time Scheduling component is not used (i.e., in a non RTLinux-based system). In this case, the loadable scheduler provided by the QoS module will be the only real-time scheduler in the system, and all the real-time/time-sensitive tasks will run at user level.

As a final note, we would like to stress that the QoS component gives to the user the freedom to choose which time-sensitive tasks to run at kernel level, and which ones to run at user level, allowing the implementation of three different kinds of solutions:

1. A ``pure RTLinux'' solution, in which all the time-sensitive tasks run at kernel level;

2. A ``pure user-level'' solution, in which all the time-sensitive tasks run in user space;

3. A ``mixed'' solution, in which some time-sensitive tasks run at kernel level (as RTLinux tasks), and the other ones run at user level. OCERA will allow to easily move a task from one level to the other without having to change the application too much.