Use of Extended Adaptive Decision Tables on Reconfigurable

IEEE LATIN AMERICA TRANSACTIONS, VOL. 12, NO. 7, OCTOBER 2014
1325
Use of Extended Adaptive Decision Tables on
Reconfigurable Operating Systems
S. M. Martin, G. E. De Luca, and N. B. Casas
1
Abstract— Throughout the last decades, many reconfigurable
operating systems have been developed in order to let users and
programmers make decisions upon the configuration of some of
the innermost kernel’s aspects. These decisions, however, require
an advanced level of skill in order to obtain some performance
advantage. Furthermore, they can be detrimental to the system’s
performance if they are not careful taken. Letting the kernel itself
do the decision-making upon the implementation of its aspects is a
safe and powerful way to manage re-configurability that does not
require interaction with the user nor the need of advanced skills to
take advantage of. In this article, we propose the usage of Extended
Adaptive Decision Tables as a mean for the kernel to achieve the
capability of taking intelligent decisions based solely on the users’
process creation behavior.
Keywords— Decision Tables, Operating Systems, Adaptive
Device
L
I. INTRODUCCIÓN
OS SISTEMAS operativos han sido desarrollados y
utilizados por décadas para abstraer tanto a los usuarios
finales como a los programadores de aplicaciones de la
complejidad del hardware subyacente. A través de ellos, la
computadora y sus componentes pueden ser vistos como
recursos administrables que los usuarios y sus aplicaciones
pueden solicitar y utilizar. La lista de recursos administrados
por un sistema operativo incluye, pero no se limita a: uso del
procesador, distribución de la memoria, permisos para
entrada/salida, y operaciones en dispositivos físicos o
virtuales, entre otros.
Los primeros sistemas operativos comerciales, como MSDOS, sólo permitían la ejecución de un único proceso en
simultáneo. Por esa razón, las funciones de su kernel estaban
limitadas solamente a inicializar, proveer una línea de
comandos, y algunos servicios básicos. Al ejecutar un
proceso, éste toma el control completo del procesador, la
memoria y los dispositivos, mientras que el kernel no tiene
ninguna responsabilidad administrativa sobre ellos.
Con el desarrollo de sistemas operativos tipo UNIX más
avanzados que permitían la ejecución de más de un proceso al
mismo tiempo y el uso simultáneo de varios usuarios,
surgieron nuevos desafíos. El problema de qué procesos o
usuarios debían tener mayor uso de procesador, o contar
1
S. M. Martin, Departamento de Ingeniería e Investigaciones Tecnológicas,
Universidad Nacional de La Matanza. Buenos Aires, Argentina,
smartin@ing.unlam.edu.ar
G. E. De Luca, Departamento de Ingeniería e Investigaciones
Tecnológicas, Universidad Nacional de La Matanza. Buenos Aires, Argentina,
gdeluca@ing.unlam.edu.ar
N. B. Casas, Departamento de Ingeniería e Investigaciones Tecnológicas,
Universidad Nacional de La Matanza. Buenos Aires, Argentina,
ncasas@ing.unlam.edu.ar
segmentos más grandes de memoria fue abordado de manera
diferente por los distintos desarrolladores de sistemas
operativos. Hoy en día, la diversidad de posibilidades para la
administración de recursos entre diferentes sistemas
operativos provee a los usuarios y empresas con una gama de
productos específicos para cada necesidad de administración.
La mayoría de los sistemas operativos de acceso público no
son reconfigurables. Esto significa que sus políticas
administración de los recursos están predefinidas y no pueden
ser cambiadas por los usuarios.
Utilizaremos la nomenclatura utilizada en nuestro trabajo
previo [1] en el que el uso del procesador, la administración de
la memoria, y el manejo de otros recursos son llamados
aspectos del sistema operativo. Cada uno de estos aspectos
puede ser administrador utilizando una política o modo. Un
sistema operativo es llamado reconfigurable cuando uno o
más de sus aspectos pueden cambiar de modo en tiempo de
ejecución, sin necesidad de reiniciar.
A pesar de que casi todos los requerimientos para sistemas
operativos comerciales y hogareños pueden ser satisfechos
con kernels convencionales (no reconfigurables), existen
beneficios potenciales para la capacidad adaptativa de un
kernel reconfigurable.
Algunos ejemplos de sistemas operativos reconfigurables,
como Kea [2] y Synthetix [3], han mostrado mejores
resultados que sus contrapartes comerciales en pruebas
conducidas sobre condiciones de ejecución y comportamiento
de procesos cambiantes. Otros, como SPIN [4], proveen una
interfaz de extensión para que el mismo programador pueda
desarrollar nuevos modos para los aspectos del kernel.
Todos los sistemas operativos reconfigurables disponibles
– listos para usar, sólo en código fuente, o sólo en bibliografía
académica – dependen de que el usuario/programador decida
tanto qué cambios realizarle a la configuración del kernel,
como cuándo hacer esos cambios. En la mayoría de los casos,
esto es logrado mediante el uso de una interfaz kernel-proceso
basada en un modelo de objetos [5] que presenta la
funcionalidad de un cierto aspecto, y permite al programador
definir qué instancia de una clase llega a ejecutarlo.
A pesar de la gran flexibilidad y potencial adaptativo que
puede ser obtenido por el método de interfaces, sus
limitaciones pueden ser frecuentemente suficientes para evitar
que usuarios, programadores, o incluso diseñadores de
sistemas operativos la usen.
Por un lado, le tomaría a un programador conocer al menos
algo sobre la implementación del kernel para poder obtener
alguna ventaja. Algunos programadores deberían incluso
investigar sobre el kernel previamente para saber qué aspectos
cambiar y cuándo cambiarlos.
Por otro lado, programas legados, estándar, o reutilizados
no tendrían la oportunidad de aprovechar sus beneficios. Ellos
podrían necesitar un proceso de reingeniería antes de que
puedan ser capaces de utilizar las interfaces de
reconfiguración adecuadamente. Los usuarios finales con
programas propios no podrían ni siquiera tener una
oportunidad de utilizar el potencial subyacente del kernel
reconfigurable.
En este artículo presentamos un punto de vista diferente
para permitir la reconfiguración de un kernel. En este enfoque,
la responsabilidad de decidir qué cambios realizar en la
configuración de los aspectos del kernel cambiar recae sobre
el sistema operativo, y no sobre los usuarios/programadores.
Las tres razones principales para soportar esta idea son:
Primero, los desarrolladores del kernel ya cuentan con
todas las habilidades y conocimiento de las complejidades de
sus aspectos y modos. Ellos pueden diseñar mejores
mecanismos para el cambio de modos de tal manera que no se
requiera un conocimiento específico de parte de los usuarios y
programadores.
Segundo, todas las aplicaciones pueden ser ejecutadas de
manera agnóstica de la capacidad reconfigurable del kernel, y
aun así aprovechar sus beneficios.
Por último, el kernel puede tomar decisiones tomando en
cuenta indicadores más complejos de los que un programador
podría tener en cuenta. Algunos de ellos serían incluso
inaccesibles para los procesos en tiempo de ejecución, y otros
podrían ser muy complejos o específicos para que el
programador los considere.
En este trabajo utilizamos Tablas de Decisión Adaptativas
Extendidas – de aquí en adelante abreviadas como EADTs –
como un dispositivo que nos permitirá a nosotros, como
diseñadores de sistemas operativos, otorgarle al kernel un
mecanismo para la toma de decisiones basadas en el
comportamiento de sus usuarios.
Todo el análisis y ejemplos presentados en este artículo
fueron conducidos sobre SODIUM (Sistema Operativo del
Departamento de Ingeniería de la Universidad Nacional de La Matanza. El
proyecto SODIUM comenzó en 2005 con el objetivo de permitirle a los
alumnos de sistemas operativos tener la oportunidad, no sólo de entender los
conceptos teóricos, pero también de involucrarse activamente en el desarrollo
de un kernel. Al final de cada año, todas las prácticas son evaluadas, y los
mejores trabajos son integrados al kernel para que los alumnos del siguiente
semestre lo utilice. Web: http://www.so-unlam.com.ar/), un proyecto para
un sistema operativo reconfigurable académico [6] [7] y, más
específicamente, su aspecto reconfigurable de planificación de
procesos.
El resto de este artículo se organiza de la siguiente manera: la
sección II introduce el aspecto reconfigurable de planificación
de procesos de SODIUM. En la sección III, dicho aspecto es
analizado para obtener un criterio de toma de decisiones
necesario para construir la tabla de decisión inicial que será
presentada en la sección IV. En la sección V se explica qué
elementos adaptativos fueron utilizados para obtener una tabla
de decisión adaptativa, En la sección VI, analizamos el
mecanismo extendido que permite definir múltiples criterios
para la toma de decisiones para generar la tabla de decisión
adaptativa extendida final. En la sección VII indicamos las
IEEE LATIN AMERICA TRANSACTIONS, VOL. 12, NO. 7, OCTOBER 2014
pruebas realizadas y los resultados obtenidos con el método
presentado. Finalmente, en la sección 7 se discuten trabajos
futuros y las conclusiones de nuestra investigación.
II. PLANIFICADOR DE PROCESOS RECONFIGURABLE SODIUM
A pesar de que este artículo presenta una propuesta general
para la toma de decisiones sobre reconfigurabilidad de un
kernel utilizando EADTs, es necesario y mucho más fácil
explicar su implementación sobre un aspecto reconfigurable
existente como base.
No hay otro aspecto reconfigurable en SODIUM que haya
sido más refinado e investigado que el planificador de
procesos. Éste cuenta con 6 diferentes modos disponibles:
Round-Robin (RR), Round-Robin con colas de prioridad
(RRPR), Round-Robin con quantum variable (RRQV), FirstCome-First-Serve
(FCFS),
Shortest-Finishing-Job-First
(SJFS), y Best-Time-Of-Service (BTS). La mayoría de estos
modos han sido especificados como estándares en la
bibliografía existente sobre sistemas operativos. Nosotros
hemos utilizado una especificación general [8] como base para
su implementación.
Este aspecto tiene la particularidad de que todos sus 6
modos pueden ser intercambiados a cualquiera de los otros sin
limitaciones, en tiempo de ejecución. Esto significa que este
aspecto cuenta con 30 transiciones diferentes para
implementar. Cada transición esta implementada como un
grupo de funciones que efectúan los cambios necesarios para
su reconfiguración.
En la Tabla I, se indica qué grupo de funciones ejecuta el
kernel de SODIUM – todas ellas son conmutativas – para
lograr cambiar un modo de planificación a otro en tiempo de
ejecución. Este es un paso necesario para permitirle al kernel
reconfigurarse de manera autónoma, y debe ser diseñado por
los desarrolladores del sistema operativo. Las acciones han
sido codificadas como letras para ilustrar indicar qué
transiciones se ejecutarán según las condiciones dadas en las
tablas de decisión mostradas en este artículo, mientras que la
transición 0 indica que ninguna acción se debe efectuar. Esta
tabla será utilizada nuevamente en la sección VI, cuando
nuevas reglas se agreguen para contemplar nuevas condiciones
de ejecución.
TABLA I. TRANSICIONES ENTRE MODOS Y SUS ACCIONES.
Siguiente Modo
RR
Modo Actual
1326
RR
RRPR
RRQV
FCFS
SJFS
BTS
0
f
k
o
t
v
RRPR RRQV FCFS
a
0
l
p
p
w
b
g
0
q
q
x
c
h
m
0
u
y
SJFS
BTS
d
i
n
r
0
z
e
j
ñ
s
s
0
A pesar de que esta tabla de transiciones-acciones le
permite al sistema operativo por sí mismo saber qué acciones
tomar para realizar una transacción, no es suficiente todavía
para permitirle tomar decisiones sobre qué transiciones
ejecutar, ni cuando tomarlas. Contar con esta relación entre
MARTIN et al.: USE OF EXTENDED ADAPTIVE DECISION
transiciones y acciones es el primer paso para generar una
tabla de decisión convencional – de ahora en adelante,
abreviada como cTD –. La cTD contendrá el primer
mecanismo de condición-acción que le permitirá al kernel
tomar decisiones autónomamente.
III. CRITERIOS PARA TOMA DE DECISIONES
Para que una tabla de transiciones-acciones, como la obtenida,
le permite a un kernel tomar decisiones autónomamente,
necesitamos definir dos nuevos elementos clave: condiciones,
que van a indicar qué reglas – como sinónimo de transición –
se deben ejecutar en un cierto momento; y eventos, que
indican cuándo se deben evaluar las condiciones.
Los eventos por sí mismos también pueden ser
considerados condiciones, porque si no ocurren, ninguna de
las reglas asociadas a ellos se ejecutará. Sin embargo, desde
un punto de vista de los sistemas operativos, la distinción es
importante. Los eventos se codifican como funciones de
gatillo puestas en diferentes partes del kernel, mientras que las
condiciones se evalúan únicamente si se recibe un evento. En
el caso del planificador de procesos de SODIUM, los eventos
se dispararán cada vez que un proceso sea creado, eliminado,
interrumpido, o liberado. Esto incluye interrupciones de
hardware/software, syscalls, solicitudes y respuestas de E/S, y
rutinas de comunicación entre procesos.
Definir condiciones como tales puede ser más difícil. Para
definir qué condiciones de ejecución requerirán un cambio de
modo, debemos evaluar tres aristas diferentes de la
planificación de procesos: métricas de planificación,
categorías de aplicación, y relaciones de algoritmos-métricas.
A. Métricas de Planificación
El planificador de procesos de SODIUM cuenta con un
conjunto de 7 métricas para evaluar y reportar el rendimiento
de cada algoritmo (modo) de planificación. Estas métricas
están basadas en la lista presentada en [8]. Aquí se muestra
una breve explicación para cada una:
• Uso del Procesador ( % cpu ) indica el radio entre el
tiempo que el procesador está ejecutando un proceso, y
el que pasa en estado libre (idle) o en operaciones de
overhead.
• Rendimiento ( # f ) indica la cantidad de procesos que
han finalizado dado un diferencial finito de tiempo.
• Tiempo de Finalización ( t cv ) indica el tiempo que le
toma a un proceso ejecutar por completo, desde que es
creado hasta que termina. Esto incluye el tiempo
esperando por memoria u operaciones de E/S.
• Tiempo de Espera ( t w ) indica el tiempo total de espera
del proceso durante toda su ejecución, desde que es
creado. Esto no incluye E/S ni syscalls.
1327
• Tiempo de Respuesta ( t r ) indica el tiempo promedio
que, para cada proceso que ha solicitado una operación,
ésta es completada.
• Tiempo efectivo de Servicio ( t s ) Indica la suma del
tiempo que el proceso ha pasado en ejecución en el
procesador.
• Overhead (Ov) indica el tiempo que el procesador pasa
ejecutando rutinas de administración de sistema.
B. Categorías de Aplicaciones
Dado que no es posible conocer exactamente qué acciones
y servicios serán ejecutados por una aplicación de usuario
antes de que ejecute por completo, la única manera de estimar
su futuro comportamiento es intentar perfilarla dentro de una
categoría bien conocida. Nos enfocamos en la técnica de
perfilado presentada en [9] basada en la frecuencia de llamado
a system calls, y la mantención de información particular por
proceso, como la especificada para el sistema operativo
Solaris en [10].
En SODIUM, los procesos en ejecución caen, luego de un
corto período de tiempo, en alguna de las siguientes
categorías: Aplicaciones de Interacción Intensiva (II), como
juegos o líneas de comando; Aplicaciones Multimedia (M),
como herramientas de edición de video y audio; Aplicaciones
de E/S Intensiva (ES), como grabadores de DVD o
transferencia de datos; Aplicaciones Internet (WEB), como
navegadores o programas de red; Aplicaciones de
Procesamiento Intensivo (P), como compiladores o programas
científicos; y Aplicaciones de Sistema (S), como servicios o
programas de mantenimiento.
Luego de conducir una batería de pruebas sobre
aplicaciones siendo categorizadas, pudimos establecer qué
métricas son más importantes para cada categoría, como se
muestra en la Tabla II.
TABLA II. MÉTRICAS DE ALTA PRIORIDAD PARA CADA CATEGORÍA.
Categorías
Aplicaciones de Interacción
Intensiva
(II)
Aplicaciones Multimedia
(M)
Aplicaciones de E/S
Intensiva
(ES)
Aplicaciones Internet
(WEB)
Aplicaciones de
Procesamiento Intensivo
(P)
Aplicaciones de Sistema
(S)
Métricas
Tiempo de Respuesta
Tiempo de Espera
Tiempo de Espera
Uso del Procesador
Rendimiento
Tiempo de Respuesta
Tiempo Efectivo de Servicio
Tiempo de Respuesta
Tiempo de Finalización
Rendimiento
Overhead
1328
IEEE LATIN AMERICA TRANSACTIONS, VOL. 12, NO. 7, OCTOBER 2014
C. Relaciones entre Métricas y Algoritmos
Dado que ahora contamos con la posibilidad de encasillar
una aplicación dentro de una categoría, mantener métricas de
planificación, y saber aproximadamente qué métricas
favorecen cada categoría, sólo nos queda determinar qué
algoritmos de planificación (modos) favorecen dichas
métricas.
Hemos encontrado alguna de estas relaciones algoritmométrica ya documentadas en bibliografía existente [8]. Sin
embargo, hemos conducido pruebas de control para
confirmarlas, y también determinar aquellas que no estaban
contempladas.
Por ahora, contemplaremos el caso de múltiples categorías
utilizando directamente el algoritmo de planificación RoundRobin que es el que mejor ha respondido en general para todas
las métricas de planificación durante las pruebas realizadas.
Los escenarios mono, multi y los de categoría única pueden
ser interpretados en una tabla de decisión como condiciones
que, sin contemplar la capacidad de que dos puedan cumplirse
al mismo tiempo, pueden determinar qué algoritmo será mejor
utilizar en cada caso. Además, de la Tabla I podemos
determinar qué acciones ejecutar para realizar las transiciones
de un modo a otro.
TABLA III. TABLA DE DECISIÓN CONVENCIONAL (CDT) PARA EL PLANIFICADOR DE PROCESOS DE SODIUM.
Reglas
1
R
R
Condiciones
Modo Actual
Aplicaciones
en ejecución
Acciones
Mono
II
M
ES
WEB
P
S
Multi
x
a
1 1 1
0 1 2
R R R R P P P P P Q Q
R R R R R R R R R V V
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
b c d e f g h i j k l
2
3
4
5
6
7
8
9
IV. TABLA DE DECISIÓN CONVENCIONAL
La información obtenida en las pruebas realizadas es
suficiente para determinar qué algoritmo de planificación
utilizar cuando todos los procesos en ejecución pertenecen a la
misma categoría. Sin embargo, este escenario no cubre todas
las posibilidades de ejecución.
Podría existir un escenario en el que sólo exista un proceso
en la cola de listos. Este caso podría ser significativo en
sistemas de procesamiento en lote. Utilizar un algoritmo
costoso en overhead en dichos casos no es conveniente, ya
que, al no haber más procesos, el sistema debería interferir lo
menos posible. Por lo tanto, podemos establecer que, en el
caso de mono-procesamiento (mono), el algoritmo a utilizar
será el de FCFS, que no es expropiativo.
Adicionalmente, un escenario más común es que diferentes
procesos de diferentes categorías intenten ejecutar
concurrentemente. En este caso, utilizar algoritmos que
respondan a una única categoría según la Tabla II, podría ser
perjudicial para el rendimiento general. Esto se debe a que
estaríamos utilizando sólo una heurística simple e información
empírica para determinar el mejor algoritmo en escenarios
complejos. De hecho, existen 720 combinaciones diferentes de
escenarios en ejecución simultánea. Esta complejidad no
puede ser manejada a priori, tan solo analizando cada
categoría por separado. Este es el escenario denominado
multi-categoría (multi) que será resuelto luego utilizando la
capacidad de auto-modificación de una tabla de decisión
adaptativa.
1
3
Q
V
x
1
4
Q
V
1
5
Q
V
1 1 1 1 2
6 7 8 9 0
F F F F F
C C C C C
2
1
S
J
2
2
S
J
x
2
3
S
J
2
5
S
J
x
x
x
x
x
x
x
x
2 2 2 2 3
6 7 8 9 0
B B B B B
T T T T T
x
x
x
x
x
x
x
x
m n
2
4
S
J
x
x
ñ
x
o
p
q
r
s
x
t
p
q
u
x
s
x
v
w x
y
z
Por lo tanto, ya contamos con todos los elementos para
construir la tabla de decisión convencional inicial (cDT), para
que el planificador de procesos del kernel de SODIUM pueda
decidir qué algoritmo utilizar dependiendo de las aplicaciones
siendo ejecutados, y además qué funciones ejecutar para
cambiar entre un modo y otro. Dicha tabla consiste en un
conjunto de 30 reglas que combinan las condiciones dadas –
modo actual y aplicaciones en ejecución– y sus acciones
correspondientes. La cDT inicial para el planificador de
SODIUM puede ser vista en la Tabla III.
V. TABLA DE DECISIÓN ADAPTATIVA
A. Mecanismo adaptativo
Para poder contemplar nuevas reglas para escenarios
complejos, tales procesos de categoría II y M ejecutándose
simultáneamente, debemos agregar mecanismos adaptativos a
la cDT estática obtenida previamente, para transformarla en
una tabla de decisión adaptativa (aDT). La definición formal
de una aDT [11] [12] requiere la especificación de una cDT
base tal como la obtenida en la Tabla III, y también la adición
de funciones adaptativas para realizar consultas,
eliminaciones, e inserciones automatizada sobre las reglas de
la tabla.
En este trabajo utilizamos un mecanismo adaptativo simple
que consiste en el uso de dos funciones adaptativas simples.
Una es utilizada para verificar la existencia de reglas que
contemplen el escenario complejo en ejecución. La otra es
utilizada para agregar una nueva regla, si es que no existe una
MARTIN et al.: USE OF EXTENDED ADAPTIVE DECISION
para el escenario detectado.
Estas funciones adaptativas, llamadas Ad1, y Ad2, se
ejecutan antes y después de la ejecución de las reglas de la
tabla propiamente dichas, respectivamente. Ad1 sólo define el
valor de la variable estado a D (determinado) si existe une
regla que pueda contemplar las condiciones actuales del
escenario. Cuando ninguna regla existente contempla las
condiciones actuales, una nueva regla (31) se encarga de
definir la variable estado a ND (no determinado). En el
siguiente paso, si el valor de la variable estado es igual a ND,
una nueva regla (32) ejecuta la función adaptativa Ad2.
La función Ad2 se encarga de agregar 6 nuevas reglas a la
tabla de decisión. Estas nuevas reglas se encargarán de
contemplar el caso actual en futuras ejecuciones. El resultado
de esto es que, en cualquier momento en el futuro en el que se
repitan las mismas condiciones, existiría una transición hacia
el modo en que esas condiciones fueron contempladas
inicialmente. La lógica de esto es que, cuando un nuevo
conjunto de condiciones es encontrado, es probablemente
porque un nuevo proceso de una categoría diferente a los que
se encuentran en ejecución es creado. Por lo tanto, se sigue
manteniendo el mejor planificador para las aplicaciones que
ya estaban creadas. Al hacer esto, se intenta mantener los
beneficios del planificador en ejecución para los procesos ya
activos. La implementación de las nuevas reglas 31 y 32, y las
funciones adaptativas Ad1 y Ad2 pueden ser vistas en la Tabla
V.
La acción que será ejecutada por cada nueva regla está dada
por la función $m que toma el modo actual de la regla, y el
escenario actual como parámetros para definir una acción
específica. El resultado de definir qué acción realizar según
los modos detectados se obtiene de los valores de $m
mostrados en la Tabla I.
Las funciones adaptativas crearán nuevas reglas para casos
particulares en los que, por ejemplo, condiciones de categoría
(M) y (S) se detectan simultáneamente. En ese caso, 6 nuevas
reglas se crearán para contemplar esa combinación de
condiciones con 6 posibles modos actuales que serán
agregadas a la cDT subyacente.
A pesar de ser un mecanismo simple, esto le permite a la
tabla de decisión aprender del comportamiento del usuario, y
convergir hacia una tabla de decisión completa con 720 reglas
diferentes, para cada usuario. Por otro lado, muestra algunas
limitaciones debido a que, una vez creadas, no pueden ser
modificadas si el usuario muestra un comportamiento
diferente en ejecuciones sucesivas. Tampoco provee la
habilidad de contemplar más criterios (métricas) en el proceso
de toma de decisiones. Estos problemas son abordados
utilizando las extensiones a la aDT mostrados en la siguiente
sección.
VI. TABLA DE DECISIÓN ADAPTATIVA EXTENDIDA
La aDT obtenida en la sección previa permite la creación de
nuevas reglas que contemplan condiciones que no fueron
incluidas en la cDT original. Sin embargo, el único criterio
utilizado para determinar las acciones de transición de modo
1329
fueron aquellas que mantienen el primer modo original. Este
criterio no contempla el uso de indicadores de rendimiento –
como las métricas definidas en la Tabla II – ni un mecanismo
para modificar las reglas ya creadas. Por lo tanto, es necesario
extender la definición de la aDT para poder incluir funciones
específicas que puedan decidir qué algoritmo utilizar
basándose en la relación entre las categorías de procesos y las
métricas mantenidas.
Recurriremos a la definición formal de una Tabla de
Decisión Adaptativa Extendida (EADT) [13] [14] en el que
múltiples criterios pueden ser definidos para determinar la
mejor decisión posible. Este definición parte de una aDT base
tal como la definida en la sección anterior a la que se le
agregan funciones auxiliares que se ejecutan antes que la
acción definidas por las regla seleccionada, y definen valores
para variables que serán tomadas en cuenta luego para la toma
de decisiones.
En nuestro caso, definimos el modo destino como
parámetro para la función $m usando las métricas definidas en
la sección III. En [13], se indica que es necesario elaborar una
matriz Z de preferencia por cada combinación de criterios
(métricas) y alternativas (algoritmos de planificación), usando
la escala fundamental de Saaty [15] para comparar la
importancia relativa de cada criterio con cada categoría de
aplicación.
Por otro lado, podemos ajustar la importancia de cada
criterio teniendo en cuenta la cantidad de procesos de cada
categoría que se encuentran listos para ejecutar. Por ejemplo,
para un escenario en el que 2 procesos de categoría (II), y uno
de categoría (S) están listos, la importancia de las métricas tw y
tr será el doble de la definida para la métrica ov.
TABLA IV. MATRIZ Z DE PREFERENCIA CRITERIO/ALTERNATIVA.
Preferencia de Criterio
Categoría
%cpu
#f
tcv
tw
tr
ts
ov
Multiplicador
RR
RRPR
RRQV
FCFS
SJFS
BTS
x1
0,35
0,35
0,12
0,06
0,06
0,06
x1
0,13
0,13
0,13
0,13
0,38
0,13
x1
0,05
0,15
0,30
0,30
0,30
0,05
x6
0,18
0,54
0,02
0,02
0,02
0,06
x6
0,16
0,16
0,02
0,02
0,02
0,16
x1
0,23
0,03
0,03
0,03
0,03
0,68
x3
0,15
0,15
0,45
0,45
0,05
0,05
Preferencia
Total
0,17
0,28
0,25
0,11
0,06
0,13
Para el ejemplo anterior, una matriz Z normalizada de
preferencias de criterios para cada alternativa es ilustrada en la
Tabla IV. Puede verse en esta tabla que, para el ejemplo, se
podrían obtener mejores resultados utilizando el algoritmo
RRPR, que obtiene una preferencia ligeramente mayor que la
del algoritmo RRQV.
La matriz Z se regenerará completamente basada en la
cantidad y categoría de los procesos listos para ejecutar cada
vez que alguna función adaptativa llame a una función
llamada z_gen(). Otra función z_get() que se utilizará para
obtener el algoritmo preferido dada la matriz generada.
Sólo será necesario agregar llamadas a las funciones
z_gen() y z_get() junto con una nueva variable m para guardar
el valor obtenido. En la Tabla V se muestra la forma final de
1330
IEEE LATIN AMERICA TRANSACTIONS, VOL. 12, NO. 7, OCTOBER 2014
ejecución. Inicialmente, cada recorrido crea dos procesos de
una categoría, evalúa las métricas, y crea otros dos nuevos
procesos de otra categoría, hasta llegar a los 12 procesos
simultáneos, con los que completa todas las categorías. Los
caminos de cada recorrido se especifican en la Tabla VI.
la tabla de decisión adaptativa extendida implementada en el
planificador de procesos de SODIUM.
TABLA V. TABLA DE DECISIÓN ADAPTATIVA EXTENDIDA IMPLEMENTADA EN SODIUM.
Declaraciones de Funciones Adaptativas
Ad1
Modo
Actual
Estado
Condiciones
Funciones de
Preferencia
Acciones
+
P
R
+
Q
V
+
F
C
+
S
J
+
B
T
C1
C2
C3
C4
C5
C6
C1
C2
C3
C4
C5
C6
C1
C2
C3
C4
C5
C6
C1
C2
C3
C4
C5
C6
C1
C2
C3
C4
C5
C6
C1
C2
C3
C4
C5
C6
II
M
ES
WEB
P
S
z_gen()
z_get()
func()
Ad1
Ad2
m
0 1 2 3
H ? H +
R
R
A
…
S R R R R
R R R
…
R R R
…
- x - …
x - - …
- - - …
- - - …
- - x …
- - - …
Reglas
2 2 2
6 7 8
R R R
F S S
C J J
x
-
x
-
2
9
R
B
T
- - - x
- - x -
3 3 3 3
0 1 2 3
R R R E
B
T
N
x
x
m
y
N
$m $m $m $m $m $m 0 a b d
…
…
q q u x
x
x
x x x x x
D
Estado=
Funciones
Adaptativas
Variables
Ad2
x
x
x
x
x
x x x
B
V
VII. PRUEBAS Y RESULTADOS
El objetivo de las pruebas a realizar es medir la eficiencia de
la decisión sobre qué modo (algoritmo) utilizar para la
planificación de procesos de cada una de las estrategias
expuestas en este trabajo. Para ello, se elaboraron tres
versiones diferentes del planificador de procesos de SODIUM,
cada una implementando una de los dispositivos de toma de
decisión obtenidos a través de este trabajo:
• Tabla de decisión convencional (cDT).
• Tabla de decisión adaptativa (aDT).
• Tabla de decisión adaptativa extendida (EADT)
Para medir la eficiencia de un algoritmo de planificación
respecto a un escenario de ejecución en particular,
obtendremos un puntaje normalizado que permita comparar su
desempeño
respecto
a
otras
combinaciones
algoritmo/escenario. Para esto se midieron los siguientes
elementos:
• La cantidad de procesos de una categoría en particular para
el escenario evaluado.
• Relevancia de cada métrica según la categoría de
aplicación según la Tabla II. Por ejemplo, para la categoría
de procesamiento intensivo (P), sólo son relevantes las
métricas Tiempo de Ciclo de Vida (tcv) y Tasa de
Finalización (#f).
Para las pruebas se establecieron seis recorridos
(denominados 1, 2, 3, 4, 5, y 6). Cada recorrido pasa por un
escenario de categoría única, y luego agrega procesos de otras
categorías escalonadamente, hasta que llega al escenario
donde procesos de todas las categorías se encuentran en
x
x
x
TABLA VI. RECORRIDOS DE LAS PRUEBAS REALIZADAS.
Recorrido
1
2
3
4
5
6
# Procesos
(II)
(M)
(ES)
(WEB)
(P)
(S)
2
(S)
(II)
(M)
(ES)
(WEB)
(P)
4
Categorías
(P)
WEB)
(ES)
(S)
(P) (WEB)
(II)
(S)
(P)
(M)
(II)
(S)
(ES)
(M)
(II)
(WEB)
(ES)
(M)
6
8
10
(M)
(ES)
(WEB)
(P)
(S)
(II)
12
En la Fig. 1 se muestra un gráfico de evolución para el
promedio de eficiencia de los diferentes métodos de toma de
decisión implementados respecto al caso ideal. La eficiencia
ideal muestra el máximo hipotético que cada método podría
obtener.
Puede observarse que la EADT obtiene los mejores
resultados para todos los casos debido a su capacidad de
combinar el potencial ofrecido por la aDT para casos
específicos, y el de la cDT para la generalización. Esto
demuestra que la EADT implementada como mecanismo
adaptativo para la selección de algoritmos puede obtener
resultados cercanos a los ideales para todo tipo de escenarios.
Los detalles de implementación y algoritmos de cálculo de
eficiencia utilizados en las pruebas se encuentran detallados en
[16].
MARTIN et al.: USE OF EXTENDED ADAPTIVE DECISION
1331
[2]
[3]
[4]
[5]
[6]
Figura 1. Gráfico de la evolución de la eficiencia entre los diferentes métodos
de toma de decisión y el caso ideal.
VIII. CONCLUSIONES Y PERSPECTIVAS FUTURAS
En el presente trabajo se ha logrado implementar con éxito un
mecanismo para la toma de decisión sobre la configuración de
un sistema operativo reconfigurable que no requiere la
intervención directa del usuario, mediante la aplicación de
tecnologías
adaptativas.
Las
decisiones
tomadas
automáticamente por el kernel permitieron obtener una
eficiencia cercana a la ideal para el aspecto de selección de
planificadores de procesos.
Con el uso de EADTs fuimos capaces de elaborar una
alternativa para determinar la configuración de un aspecto de
un sistema operativo que sería demasiado compleja o
inaccesible de determinar a priori. También pudimos proveer
al kernel de SODIUM con la capacidad de cambiar reglas
existentes basándose en el comportamiento de aplicaciones y
usuarios. Mientras que estas capacidades podrían ser obtenidas
con otros dispositivos para la de toma de decisión, ésta
alternativa se destaca en que provee un mecanismo intuitivo
para determinar las reglas y funciones adaptativas.
Respecto a SODIUM, existen muchos más aspectos de
kernel que todavía no han sido analizados y convertidos a
aspectos reconfigurables adaptativos. Este trabajo será
realizado durante la siguiente etapa de investigación del
equipo de desarrollo, en las cuales se harán nuevas mediciones
para observar si los beneficios del uso de EADTs pueden ser
obtenidos para cualquier aspecto.
Las perspectivas del uso de mecanismos adaptativos para la
reconfiguración
automatizada
(no
interactiva)
son
prometedoras. Estas podrían ser aplicadas en cualquier sistema
operativo hogareño o empresarial que exista en el mercado sin
necesidad de hacer una reingeniería de sus aplicaciones. En
este caso, un costo inicial será necesario para adaptar el
kernel: se deben desarrollar las funciones y métricas a tener en
cuenta como datos de ingreso para sus EADTs, se deben
analizar los diferentes modos de implementación, y los
eventos a definir.
REFERENCIAS
[1]
S. MARTIN, N. CASAS, G. DE LUCA, “Diseño de un sistema operativo
reconfigurable para fines didácticos y prácticos”. 6° Workshop de
Tecnologia Adaptativa. San Pablo, Brasil, 2012.
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
A. C. VEITCH, N. C. HUTCHINSON, “Kea – a dynamically extensible
and configurable operating system kernel”, 3rd International
Conference on Configurable Distributed Systems. Vancouver,
Canada, 1996.
C. COWAN, T. C. AUTREY, C. KRASIC, C. PU, J. WALPOLE, “Fast
concurrent dynamic linking for an adaptive operating system”. 3rd
International Conference on Configurable Distributed Systems.
Vancouver, Canada, 1996.
B. N. BERSHAD, S. SAVAGE, P. PARDYAK, E. G. SIRER, M. E.
FIUCZYNSKI, D. BECKER, C. CHAMBERS, S. EGGERS, “Extensibility:
Safety and Performance in the SPIN Operating System”. 5th
Symposium on Operating Systems Principles. ACM, New York,
United States, 1995.
R. LEA, Y. YOKOTE, J. ITOH. “Adaptive operating system design using
reflection”. Object-Based Parallel and Distributed Computation.
Volume 1107, Springer Berlin, 1996.
N. CASAS, G. DE LUCA, M. CORTINA, G. PUYO, W. VALIENTE,
“Implementación de distintos tipos de memoria en un sistema
operativo didáctico”. XIV Congreso Argentino de Ciencia de la
Computación. La Rioja, Argentina, 2008.
H. RYCKEBOER, N. CASAS, G. DE LUCA, “Construcción de un Sistema
Operativo Didáctico”. X Workshop de Investigadores en Ciencias de
la Computación. La Pampa, Argentina, 2008.
A. SILBERSCHATZ, P. B. GALVIN, G. GAGNE. “Operating System
Concepts”. 8va Edición. John Wiley & Sons, New Jersey, United
States, 2012.
S. M. VARGHESE, K. P. JACOB, “Process Profiling Using Frequencies
of System Calls”. The Second International Conference on
Availability, Reliability and Security (ARES'07). Viena, Austria,
2007.
R. MCDOUGALL, J. MAURO, “Solaris Internals”. Second Edition.
Prentice-Hall. California, United States, 2007.
J. J. NETO, “Adaptative rule-driven devices - general formulation and
a case study”. Sixth International Conference on Implementation and
Application of Automata. Pretoria, South Africa, 2001.
T. PEDRAZZI, A. TCHEMRA, R. ROCHA, “Adaptive Decision Tables A
Case Study of their Application to Decision-Taking Problems”.
Adaptive and Natural Computing Algorithms, Springer. Vienna,
Austria, 2005.
A. H. TCHEMRA, “Tabela de decisão adaptativa na tomada de decisões
multicritério”. Phd Thesis. Escola Politécnica, USP, San Pablo, Brasil,
2009
A. H. TCHEMRA, “Adaptatividade na Tomada de Decisão
Multicritério”. 4° Workshop de Tecnologia Adaptativa. Escola
Politécnica, USP, San Pablo, Brasil, 2010.
T. L. SAATY, “Método de Análise Hierárquica”. McGraw-Hill. San
Pablo, Brasil, 1991.
S. MARTIN, “Aplicación de Tecnologías Adaptativas - Caso de
Estudio: Sistemas Operativos Reconfigurables”. Tesis de Maestría.
Universidad Nacional de La Matanza. Buenos Aires, Argentina, 2013.
Sergio Miguel Martin se graduó en la carrera de Ingeniería
en Informática en la Universidad Nacional de La Matanza
(UNLaM). de Buenos Aires, Argentina el año 2010 donde
también realizó su Maestría en el año 2013. Es docente
ayudante de las materias de Sistemas Operativos desde el
2010; de Autómatas y Lenguajes Formales desde el 2011.
Graciela Elisabeth De Luca es Analista Universitaria de
Sistemas de La Universidad Tecnológica Nacional y
Licenciada en Informática de la Universidad Católica de
Salta. Desde el año 2005 pertenece al grupo de Investigación
en Sistemas Operativos de la Universidad Nacional de la
Matanza.
Nicanor Blas Casas es Analista Universitario de Sistemas de
la Universidad Tecnológica Nacional e Ingeniero en
Informática de la universidad Católica de Salta. Desde el año
2005 pertenece al grupo de Investigación en Sistemas
Operativos de la Universidad Nacional de la Matanza.