Documentation

Sofware architecture

Design Goals and Architecture overview

• Portability: we designed a layered structure where kernel dependent code is confined inside the lowermost level. Moreover, the changes made on the kernel are minimal
• Backward compatibility: we did not change the API of the Linux Kernel.
• Flexibility: our architecture allows one to easily introduce new control and prediction algorithms, different from those proposed by default. These algorithms can be run either in user or in kernel space.
• Efficiency: the overhead introduced by QoS management mechanisms is acceptable. Moreover, the overhead is negligible in case the tasks do not use the QoS management.
• Security: the system administrator can define ``maximum'' CPU bandwidths on a per-user basis (in the same way as disk quotas).

The proposed architecture is depicted in the figure and it is composed of the following main components:

• the Generic Scheduler Patch (GSP), a small patch to the kernel (115 added lines, 7 modified files) which allows us to extend the Linux scheduler functionality by intercepting scheduling events and executing external code in a kernel module;
• the QoS Reservation component, composed of a kernel module and of an application library communicating through a Linux virtual device:
  • the Resource Reservation module implements an EDF scheduler, the resource reservation mechanism (based on EDF scheduler) and the RR supervisor; a set of compile-time configuration options allows one to use different Resource Reservation (RR) primitives, and to customise their exact semantics (e.g. soft or hard reservations);
  • the Resource Reservation library provides an API allowing an application to use resource reservation functions;
• the QoS Manager component, composed of a kernel module, an application library, and a set of predictor and feedback subcomponents which may be configured to be compiled either within the library or within the kernel module. It uses the RR module to allocate the CPU resource:
  • the QoS Manager module offers kernel-space implementations of the feedback control and prediction algorithms shown in this paper;
  • the QoS Manager library provides an API allowing an application to use QoS management functionalities; as far as the control computation is concerned, the library either implements the control loop (if the controller and predictor algorithms are in user-space) or redirects all requests to the Qos Manager kernel module (in case a kernel-space implementation is required). In the former case, the library communicates with the Resource Reservation module (using the RR library) to take measurements of the scheduling error or to require bandwidth changes. Consistently with the feedback scheme presented in the previous section, such requests are ``filtered'' by the QoS supervisor.

For more information, in particular on Generic Scheduler Patch, read "Implementing Resource Reservations in Linux"