AQuoSA

En el nivel más básico, un parche para el kernel de Linux añade la capacidad de notificar a los módulos cargados dinámicamente cualquier evento de planificación relevante. Estos eventos se han identificado en la creación o finalización de tareas, así como en los eventos de bloqueo y desbloqueo. Este parche es mínimamente invasivo, ya que consiste en unas pocas líneas de código insertadas principalmente en el código del planificador de Linux (sched.c). Se le ha denominado "Parche Genérico del Planificador" porque potencialmente permite implementar cualquier política de planificación.

La capa de Reservas de Recursos se compone de tres componentes.

El componente principal es un módulo del kernel de carga dinámica que implementa un paradigma de planificación de reservas de recursos para la CPU, aprovechando la funcionalidad introducida en el kernel de Linux a través del parche del planificador genérico.

En segundo lugar, una biblioteca de nivel de usuario (biblioteca QRES) permite que una aplicación utilice la nueva política de planificación mediante un conjunto completo y bien diseñado de llamadas a la API . Básicamente, estas llamadas permiten que una aplicación solicite al sistema que reserve un determinado porcentaje de la CPU para sus procesos.

En tercer lugar, un componente a nivel de núcleo (el Supervisor) gestiona todas las solicitudes de las aplicaciones a través de la biblioteca QRES, de modo que la suma total de las participaciones de CPU solicitadas no infrinja la condición de planificabilidad del planificador (menor que uno, o ligeramente menor que uno, debido a la sobrecarga). El comportamiento del Supervisor es totalmente configurable por el administrador del sistema , lo que permite especificar, para cada usuario o grupo, los valores mínimos garantizados y máximos permitidos para las reservas de CPU.

Con AQuoSA, las aplicaciones pueden usar directamente la capa de reserva de recursos, lo que les permite reservar una fracción de la CPU para ejecutarse con las garantías de planificación necesarias. Por ejemplo, una aplicación multimedia puede solicitar al sistema operativo que la ejecute con la garantía de que se planifique durante al menos Q milisegundos cada P milisegundos, donde Q y P dependen de la naturaleza de la aplicación.

Al registrar una aplicación en la capa de reserva de recursos, es posible especificar una reserva mínima garantizada que el sistema debe asegurar siempre a la aplicación. En función de las solicitudes de reservas mínimas garantizadas, la capa realiza un control de admisión ; es decir, permite la entrada de una nueva aplicación solo si, tras su incorporación, el nuevo conjunto de aplicaciones en ejecución no supera el límite de saturación de la CPU.

Para aplicaciones multimedia típicas que utilizan tecnologías de alta compresión, puede resultar bastante difícil, poco práctico o inconveniente ejecutarlas con una asignación fija de recursos de la CPU. De hecho, la asignación más eficiente puede variar con el tiempo debido a los diferentes niveles de compresión, lo que conlleva variaciones en el tiempo de descompresión.

Los sistemas tradicionales en tiempo real utilizan técnicas de análisis WCET (tiempo de ejecución en el peor de los casos) para calcular cuál es el tiempo máximo que una instancia de, por ejemplo, una tarea periódica puede ejecutarse en la CPU antes de bloquearse a la espera de la siguiente instancia.

Este tipo de análisis resulta muy difícil en las complejas aplicaciones multimedia actuales, especialmente cuando se ejecutan en hardware de propósito general como los PC estándar, donde tecnologías como las cachés multinivel, las canalizaciones de ejecución de la CPU, los búferes en el bus y los buses multimaster introducen muchas variables impredecibles a la hora de determinar el tiempo necesario para los accesos a la memoria.

En este tipo de sistemas, resulta mucho más conveniente ajustar el diseño en función de la carga media prevista de la aplicación. De lo contrario, el sistema podría estar significativamente infrautilizado durante su ejecución.

Como ya se mencionó, para ciertas clases de aplicaciones multimedia, como un reproductor de video , es prácticamente imposible encontrar un valor fijo adecuado para la fracción de CPU que requiere la aplicación en tiempo de ejecución, debido a las fuertes fluctuaciones de la carga que dependen de los datos que procesa. Una reserva fija basada en los requisitos promedio, o ligeramente superior, genera periodos transitorios de baja calidad durante la ejecución (por ejemplo, al reproducir películas). Por otro lado, una reserva fija basada en la carga máxima esperada resulta en una sobreasignación innecesaria de la CPU la mayor parte del tiempo, excepto en los periodos en que la carga se aproxima realmente al valor máximo esperado.

Para este tipo de aplicaciones, resulta mucho más conveniente utilizar las técnicas de reserva adaptativa, como las que proporciona la capa de reserva adaptativa de AQuoSA, que realiza una monitorización continua en línea de los requisitos computacionales de los procesos de la aplicación, de modo que pueda adaptar dinámicamente la reserva realizada en la CPU en función de los datos monitorizados.

La capa de Reserva Adaptativa expone a las aplicaciones una API para utilizar un conjunto de controladores que son de uso bastante general dentro de una amplia gama de aplicaciones multimedia.

La mayoría de las variantes de Linux en tiempo real requieren que los usuarios de las funcionalidades en tiempo real del sistema operativo modificado tengan privilegios de administrador. Esto es perfectamente aceptable en un sistema embebido . Sin embargo, resulta excesivo para sistemas multiusuario donde se necesitan funciones de programación en tiempo real para aplicaciones multimedia o similares. Por lo tanto, AQuoSA incorpora un modelo de control de acceso específico mediante el cual los administradores del sistema pueden:

1. definir cuotas de programación en tiempo real para usuarios individuales o grupos, en términos de valores máximos para el ancho de banda mínimo garantizado que el sistema operativo puede otorgar a usuarios individuales o grupos en su conjunto;
2. controlar cómo se distribuyen los valores de ancho de banda opcionales requeridos, que exceden las cifras mínimas garantizadas, entre los usuarios que compiten, en situaciones de sobrecarga;
3. Controlar la sobrecarga máxima de programación que se puede imponer al sistema debido a las reservas en tiempo real creadas por usuarios individuales o grupos; por ejemplo, permitiendo controlar cuál es el período mínimo que se puede especificar en una reserva en tiempo real.

Se pueden encontrar más detalles en el artículo sobre el tema publicado en RTAS 2008. ^{[ 2 ]}