PROYECTO FIN DE CARRERA
INGENIER´IA T´ECNICA EN INFORM´ATICA DE SISTEMAS
Karma Linux 2008
Distribuci´on de Linux para la E...
D. Ezequiel Herruzo G´omez, Profesor Colaborador de Primer Nivel
del ´Area de Arquitectura y Tecnolog´ıa de Computadores d...
Copyright c 2008 Fernando Garc´ıa, Ezequiel Herruzo, J. Ignacio Benavides
Se otorga permiso para copiar, distribuir y/o mo...
Karma Linux 2008
Distribuci´on de Linux para la Evaluaci´on de Rendimiento en
Sistemas Computacionales Modernos
Autor
Fern...
´Indice general
1. Introducci´on 1
1.1. Eventos del Procesador . . . . . . . . . . . . . . . . . . . . . 2
1.1.1. Perfctr ...
iv ´INDICE GENERAL
2.5. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.1. Factores Dato . . . ...
´INDICE GENERAL v
4.3. Dise˜no de la Interfaz . . . . . . . . . . . . . . . . . . . . . . . 69
4.3.1. Generar Medici´on . ...
vi ´INDICE GENERAL
A.4. Ayuda y Licencia . . . . . . . . . . . . . . . . . . . . . . . . . 113
B. Manual de C´odigo 115
B....
´Indice de figuras
3.1. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . 29
3.2. Diagrama de Clases . . . . ....
´Indice de cuadros
3.1. Plantilla para la Definici´on de Casos de Uso . . . . . . . . . . 30
3.2. Ejemplo de Fichero CSV re...
Cap´ıtulo 1
Introducci´on
En ciertas ocasiones, la ejecuci´on de programas se ve condicionada por
la necesidad de una resp...
2 1.1. Eventos del Procesador
procesadores l´ogicos dentro de un ´unico procesador f´ısico, lo que supone una
mejora en el...
Introducci´on 3
1.1.1. Perfctr y Performance API
Linux Performance-Monitoring Counters Driver (Perfctr) es una biblio-
tec...
4 1.2. Sistemas Operativos en Tiempo Real
si un proceso requiere 20000 ms de tiempo de procesador para llevar a cabo
su ej...
Introducci´on 5
trasos debidos a swapping3, por lo que los datos deber´ıan ser almacenados
en memoria principal. Adem´as, ...
6 1.2. Sistemas Operativos en Tiempo Real
sador almacena el estado actual y salta a la direcci´on en su espacio de
memoria...
Introducci´on 7
cuando una tarea utiliza memoria que no ha sido reservada4. A esto se le
llama tambi´en protecci´on de mem...
Cap´ıtulo 2
Definici´on del Problema
2.1. Identificaci´on del Problema Real
La informaci´on acerca del rendimiento es crucia...
10 2.2. Identificaci´on del Problema T´ecnico
n´umero de entornos posible. De esta manera, el dise˜no de nuestro sistema de...
Definici´on del Problema 11
Dicho programa puede, por lo tanto, haber sido escrito en C, Fortran o
cualquier lenguaje que p...
12 2.2. Identificaci´on del Problema T´ecnico
comprimida del sistema, en este caso con todas las caracter´ısticas requeri-
...
Definici´on del Problema 13
que cada d´ıa ampl´ıan su soporte a nuevas arquitecturas o familias de proce-
sadores. Este hec...
14 2.2. Identificaci´on del Problema T´ecnico
La distribuci´on sigue las indicaciones de la Linux Standard Base
(LSB), con ...
Definici´on del Problema 15
Las fases de desarrollo del proyecto ser´an:
Fase de Preparaci´on Durante esta fase se reunir´a...
16 2.3. Objetivos
deber´a tener acceso f´ısico al mismo, o acceder por red conociendo el usuario
y contrase˜na con protoco...
Definici´on del Problema 17
limitar la informaci´on expuesta al no poder a˜nadir, por ejemplo, gr´aficas
para ilustrar la ej...
18 2.4. Antecedentes
punto de partida principal del proyecto, Karma Linux, y por ´ultimo comenta-
remos algunas soluciones...
Definici´on del Problema 19
Intel Vtune Analiza el rendimiento de programas para Windows y Linux.
Est´a dise˜nado para desa...
20 2.4. Antecedentes
donde su uso est´a m´as ampliamente extendido. M´as formalmente puede en-
tenderse que un benchmark e...
Definici´on del Problema 21
2.5. Restricciones
A continuaci´on se expondr´an las restricciones o factores limitativos exis-...
22 2.5. Restricciones
Enfoque del trabajo hacia la arquitectura x86, arquitectura de mayor
uso y mayor facilidad de acceso...
Definici´on del Problema 23
Uso de Python para la realizaci´on de la interfaz gr´afica. Este factor
estrat´egico se debe a l...
24 2.6. Recursos para el Desarrollo
Recursos humanos internos:
Directores Prof. D. Ezequiel Herruzo G´omez y Prof. Dr. Jos...
Definici´on del Problema 25
Int´erprete de Python 2.4: para la ejecuci´on de la interfaz gr´afica de
usuario.
Biblioteca WxP...
26 2.7. Recursos para la Ejecuci´on
2.7.1. Recursos Humanos
Cualquier persona puede insertar el Live CD en su m´aquina e i...
Cap´ıtulo 3
An´alisis del Sistema
Si en cap´ıtulo anterior se ofreci´o una visi´on global del problema a resol-
ver, descr...
28 3.2. Modelado Est´atico
Uso de herramientas libres La idea es aprovechar y contribuir en el tra-
bajo de una comunidad ...
An´alisis del Sistema 29
3.2.1. Casos de Uso
3.2.1.1. Identificaci´on de los Actores
El ´unico actor implicado es el usuari...
30 3.2. Modelado Est´atico
3.2.1.3. Especificaci´on de los Casos de Uso
A continuaci´on especificaremos de modo formal cada ...
An´alisis del Sistema 31
Se podr´an guardar los resultados de la medici´on (Punto de
Extensi´on: Guardar Resultados). En e...
32 3.2. Modelado Est´atico
1. Actores: Usuario
2. Precondiciones: -
3. Flujo Principal: El usuario debe seleccionar medici...
An´alisis del Sistema 33
3.2.2.2. Descripci´on de las Clases
A continuaci´on describimos la clases indicadas en el diagram...
34 3.3. Modelado Din´amico
comunicaci´on con las clases no se vea modificada. Al ser una capa de
abstracci´on menor, y por ...
An´alisis del Sistema 35
funcionalidad por este sentido. Podr´ıamos haber a˜nadido tambi´en al final (a
la altura de Guarda...
36 3.3. Modelado Din´amico
de ejecuci´on exclusiva, hemos determinado no obstante que tendr´an
que aparecer todas las opci...
An´alisis del Sistema 37
14. La GUI rellena los paneles de resultados (y la gr´afica en caso de ser
necesario hacerlo) de a...
38 3.4. Descripci´on de la Informaci´on
Figura 3.4: Diagrama de Secuencia: Cargar Medici´on
5. La Interfaz de I/O obtiene ...
An´alisis del Sistema 39
de las mediciones. Si estamos inmersos en un proceso de evaluaci´on del
funcionamiento de una apl...
40 3.4. Descripci´on de la Informaci´on
Contador,Resultado,Tiempo,Tiempo Sys
NOMBRECONTADOR0,RESULTADO,TIEMPO,TIEMPOSYS
NO...
An´alisis del Sistema 41
el usuario final y asegurar´a que el Caso de Uso de almacenaje de los datos
sea totalmente funcion...
42 3.5. Requisitos de la Interfaz
Figura 3.6: Ejemplo de Fichero CSV: Tres mediciones
La interfaz debe permitir la configur...
An´alisis del Sistema 43
La interfaz deber´a emitir mensajes de error cuando falten datos por
introducir y/o estos datos s...
44 3.6. Descripci´on y Especificaciones del Resto del Sistema
tiempo de ejecuci´on es calculado din´amicamente permitiendo ...
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Karma Linux
Upcoming SlideShare
Loading in …5
×

Karma Linux

536
-1

Published on

Karma Linux is a Linux distribution for deterministic application performance evaluation. It has been successfully used in a Computer Engineering Processor Design and Configuration Assessment course at the University of Cordoba.

The evaluation of performance is driven by GLPerfex, a graphical tool that provides access to a set of performance counters—using the PAPI library [1]—and allows the task to have exclusive use of the CPU—using RTAI [2]. As a result, the system provides a deterministic environment to perform a non intrusive evaluation of applications.

GLPerfex and LPerfex are free software under the GNU GPL v3 license.

[1] Performance Application Programming Interface (PAPI), http://icl.cs.utk.edu/papi/
[2] Real Time Application Interface (RTAI), https://www.rtai.org/less

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
536
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Karma Linux

  1. 1. PROYECTO FIN DE CARRERA INGENIER´IA T´ECNICA EN INFORM´ATICA DE SISTEMAS Karma Linux 2008 Distribuci´on de Linux para la Evaluaci´on de Rendimiento en Sistemas Computacionales Modernos Autor Fernando Garc´ıa Aranda Directores Ezequiel Herruzo G´omez Jos´e Ignacio Benavides Ben´ıtez ESCUELA POLIT´ECNICA SUPERIOR UNIVERSIDAD DE C´ORDOBA Junio - 2008
  2. 2. D. Ezequiel Herruzo G´omez, Profesor Colaborador de Primer Nivel del ´Area de Arquitectura y Tecnolog´ıa de Computadores del Departamento de Arquitectura de Computadores, Electr´onica y Tecnolog´ıa Electr´onica de la Universidad de C´ordoba. D. Jos´e Ignacio Benavides Ben´ıtez, Catedr´atico de Escuelas Universitarias del ´Area de Arquitectura y Tecnolog´ıa de Computadores del Departamento de Arquitectura de Computadores, Electr´onica y Tecnolog´ıa Electr´onica de la Universidad de C´ordoba. Informan: Que el proyecto de fin de carrera de Ingenier´ıa T´ecnica en Inform´atica de Sistemas titulado ((Distribuci´on de Linux para la Evaluaci´on de Rendimiento en Sistemas Computacionales Modernos)) ha sido realizado bajo su direcci´on por Fernando Garc´ıa Aranda en la Escuela Polit´ecnica Superior de la Universidad de C´ordoba, reuniendo, a su juicio, las condiciones exigidas a este tipo de trabajos. Y para que conste, firman el presente informe en C´ordoba a 10 de julio de 2008. Los directores: D. Ezequiel Herruzo G´omez D. J. Ignacio Benavides Ben´ıtez
  3. 3. Copyright c 2008 Fernando Garc´ıa, Ezequiel Herruzo, J. Ignacio Benavides Se otorga permiso para copiar, distribuir y/o modificar este docu- mento bajo los t´erminos de la Licencia de Documentaci´on Libre de GNU, Versi´on 1.2 o cualquier otra versi´on posterior publicada por la Free Software Foundation; sin Secciones Invariantes ni Textos de Cubierta Delantera ni Textos de Cubierta Trasera. Una copia de la licencia est´a incluida en la secci´on titulada “GNU Free Documentation License” del Ap´endice de Licencias.
  4. 4. Karma Linux 2008 Distribuci´on de Linux para la Evaluaci´on de Rendimiento en Sistemas Computacionales Modernos Autor Fernando Garc´ıa Aranda Directores Ezequiel Herruzo G´omez Jos´e Ignacio Benavides Ben´ıtez
  5. 5. ´Indice general 1. Introducci´on 1 1.1. Eventos del Procesador . . . . . . . . . . . . . . . . . . . . . 2 1.1.1. Perfctr y Performance API . . . . . . . . . . . . . . . 3 1.1.2. Ruidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Sistemas Operativos en Tiempo Real . . . . . . . . . . . . . . 4 1.2.1. Planificaci´on de tareas . . . . . . . . . . . . . . . . . . 4 1.2.2. Manejo de Interrupciones . . . . . . . . . . . . . . . . 5 1.2.3. Comunicaci´on y Sincronizaci´on . . . . . . . . . . . . . 6 1.2.4. Gesti´on de la memoria . . . . . . . . . . . . . . . . . . 6 2. Definici´on del Problema 9 2.1. Identificaci´on del Problema Real . . . . . . . . . . . . . . . . 9 2.2. Identificaci´on del Problema T´ecnico . . . . . . . . . . . . . . 10 2.2.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . 10 2.2.2. Entorno . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.3. Vida Esperada . . . . . . . . . . . . . . . . . . . . . . 12 2.2.4. Ciclo de Mantenimiento . . . . . . . . . . . . . . . . . 12 2.2.5. Competencia . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.6. Aspecto Externo . . . . . . . . . . . . . . . . . . . . . 13 2.2.7. Estandarizaci´on . . . . . . . . . . . . . . . . . . . . . . 13 2.2.8. Calidad y Fiabilidad . . . . . . . . . . . . . . . . . . . 14 2.2.9. Programa de Tareas . . . . . . . . . . . . . . . . . . . 14 2.2.10. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.11. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.1. Adaptaci´on de Karma a Procesadores Multin´ucleo . . 16 2.3.2. Mejora de la Usabilidad . . . . . . . . . . . . . . . . . 16 2.3.3. Autonom´ıa de la Plataforma . . . . . . . . . . . . . . 17 2.4. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.1. Antecedentes a Lperfex y Glperfex . . . . . . . . . . . 18 2.4.2. Antecedentes de Planificadores en Tiempo Real . . . . 19 2.4.3. Antecedentes de la Distribuci´on . . . . . . . . . . . . . 19 2.4.4. Antecedentes a Sistemas de Benchmarking . . . . . . . 19 iii
  6. 6. iv ´INDICE GENERAL 2.5. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.1. Factores Dato . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.2. Factores Estrat´egicos . . . . . . . . . . . . . . . . . . . 21 2.6. Recursos para el Desarrollo . . . . . . . . . . . . . . . . . . . 23 2.6.1. Recursos Humanos . . . . . . . . . . . . . . . . . . . . 23 2.6.2. Recursos Hardware . . . . . . . . . . . . . . . . . . . . 24 2.6.3. Recursos Software . . . . . . . . . . . . . . . . . . . . 24 2.7. Recursos para la Ejecuci´on . . . . . . . . . . . . . . . . . . . 25 2.7.1. Recursos Humanos . . . . . . . . . . . . . . . . . . . . 26 2.7.2. Recursos Hardware . . . . . . . . . . . . . . . . . . . . 26 2.7.3. Recursos Software . . . . . . . . . . . . . . . . . . . . 26 3. An´alisis del Sistema 27 3.1. Identificaci´on de Requisitos . . . . . . . . . . . . . . . . . . . 27 3.2. Modelado Est´atico . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2.1. Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.2. An´alisis de Clases del Sistema . . . . . . . . . . . . . . 32 3.3. Modelado Din´amico . . . . . . . . . . . . . . . . . . . . . . . 34 3.3.1. Diagramas de Secuencia . . . . . . . . . . . . . . . . . 34 3.4. Descripci´on de la Informaci´on . . . . . . . . . . . . . . . . . . 38 3.4.1. El Formato CSV . . . . . . . . . . . . . . . . . . . . . 39 3.4.2. Nuestro Uso de CSV . . . . . . . . . . . . . . . . . . . 40 3.5. Requisitos de la Interfaz . . . . . . . . . . . . . . . . . . . . . 41 3.6. Descripci´on y Especificaciones del Resto del Sistema . . . . . 43 3.6.1. Planificaci´on de Procesos . . . . . . . . . . . . . . . . 43 3.6.2. Descripci´on de Componentes . . . . . . . . . . . . . . 45 3.6.3. Requisitos Funcionales . . . . . . . . . . . . . . . . . . 54 3.6.4. Requisitos No Funcionales . . . . . . . . . . . . . . . . 56 4. Dise˜no del Sistema 59 4.1. Dise˜no del Entorno de Ejecuci´on . . . . . . . . . . . . . . . . 59 4.1.1. Compilaci´on y Preparaci´on del Kernel . . . . . . . . . 60 4.1.2. Creaci´on del Entorno en Tiempo Real . . . . . . . . . 61 4.1.3. Creaci´on del Entorno de Medici´on de Eventos . . . . . 62 4.1.4. Integraci´on del Sistema de Medici´on en el kernel de Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.2. Dise˜no de la Aplicaci´on . . . . . . . . . . . . . . . . . . . . . 63 4.2.1. Clase MainFrame . . . . . . . . . . . . . . . . . . . . . 63 4.2.2. Clase Configuration . . . . . . . . . . . . . . . . . . . 64 4.2.3. Clase Counters . . . . . . . . . . . . . . . . . . . . . . 65 4.2.4. Clase CheckListCtrl . . . . . . . . . . . . . . . . . . . 66 4.2.5. Clase Results . . . . . . . . . . . . . . . . . . . . . . . 66 4.2.6. Clase ResultsPanel . . . . . . . . . . . . . . . . . . . . 67 4.2.7. Clase IOInterface . . . . . . . . . . . . . . . . . . . . . 68
  7. 7. ´INDICE GENERAL v 4.3. Dise˜no de la Interfaz . . . . . . . . . . . . . . . . . . . . . . . 69 4.3.1. Generar Medici´on . . . . . . . . . . . . . . . . . . . . 69 4.3.2. Cargar Resultado . . . . . . . . . . . . . . . . . . . . . 72 4.4. Dise˜no del Sistema Aut´onomo . . . . . . . . . . . . . . . . . . 73 4.4.1. Instalaci´on de Live Helper . . . . . . . . . . . . . . . . 74 4.4.2. Configuraci´on del Live CD B´asico . . . . . . . . . . . 74 4.4.3. A˜nadiendo Funcionalidades al Live CD B´asico . . . . 75 4.4.4. El entorno chroot . . . . . . . . . . . . . . . . . . . . . 77 4.4.5. Cerrando el Live CD . . . . . . . . . . . . . . . . . . . 78 5. Pruebas 79 5.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.2. Pruebas de Unidad . . . . . . . . . . . . . . . . . . . . . . . . 80 5.2.1. Pruebas de Casos de Uso . . . . . . . . . . . . . . . . 80 5.2.2. Pruebas de Escenarios de la Aplicaci´on . . . . . . . . 82 5.3. Pruebas de la Aplicaci´on . . . . . . . . . . . . . . . . . . . . . 84 5.3.1. Procedimiento Seguido . . . . . . . . . . . . . . . . . . 84 5.3.2. Ejecuci´on de los Casos de Prueba de la Aplicaci´on . . 85 5.4. Pruebas de Rendimiento de la Aplicaci´on . . . . . . . . . . . 87 5.4.1. Pruebas No Exclusivas Sin Ruido . . . . . . . . . . . . 88 5.4.2. Pruebas No Exclusivas Con Ruido . . . . . . . . . . . 89 5.4.3. Pruebas Bajo el Entorno Exclusivo . . . . . . . . . . . 89 6. Conclusiones y Futuras Mejoras 93 6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 6.1.1. Conclusiones personales . . . . . . . . . . . . . . . . . 94 6.2. Futuras mejoras . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Bibliograf´ıa 97 A. Manual de Usuario 101 A.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 A.1.1. Requisitos del Sistema Completo . . . . . . . . . . . . 102 A.1.2. Requisitos de Glperfex . . . . . . . . . . . . . . . . . . 102 A.2. Instalaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 A.2.1. Instalaci´on de Karma Linux 2008 . . . . . . . . . . . . 103 A.2.2. Instalaci´on de la Aplicaci´on . . . . . . . . . . . . . . . 105 A.3. Uso de la Aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . 106 A.3.1. Abrir Glperfex . . . . . . . . . . . . . . . . . . . . . . 106 A.3.2. Generar Medici´on con Planificador Est´andar . . . . . 106 A.3.3. Generar Medici´on Exclusiva . . . . . . . . . . . . . . . 110 A.3.4. Guardar Resultados de una Medici´on . . . . . . . . . 111 A.3.5. Guardar Gr´afica de una Medici´on . . . . . . . . . . . . 111 A.3.6. Cargar una Medici´on Previa . . . . . . . . . . . . . . . 112
  8. 8. vi ´INDICE GENERAL A.4. Ayuda y Licencia . . . . . . . . . . . . . . . . . . . . . . . . . 113 B. Manual de C´odigo 115 B.1. Referencia de la Clase glperfex::MainFrame . . . . . . . . . . 116 B.1.1. Descripci´on detallada . . . . . . . . . . . . . . . . . . 117 B.1.2. Documentaci´on de las funciones miembro . . . . . . . 117 B.2. Referencia de la Clase configuracion::Configuration . . . . . . 124 B.2.1. Descripci´on detallada . . . . . . . . . . . . . . . . . . 125 B.2.2. Documentaci´on de las funciones miembro . . . . . . . 125 B.3. Referencia de la Clase contadores::Counters . . . . . . . . . . 130 B.3.1. Descripci´on detallada . . . . . . . . . . . . . . . . . . 131 B.3.2. Documentaci´on de las funciones miembro . . . . . . . 132 B.4. Referencia de la Clase contadores::CheckListCtrl . . . . . . . 135 B.4.1. Descripci´on detallada . . . . . . . . . . . . . . . . . . 136 B.4.2. Documentaci´on de las funciones miembro . . . . . . . 137 B.5. Referencia de la Clase resultados::Results . . . . . . . . . . . 137 B.5.1. Descripci´on detallada . . . . . . . . . . . . . . . . . . 138 B.5.2. Documentaci´on de las funciones miembro . . . . . . . 139 B.6. Referencia de la Clase resultados::ResultsPanel . . . . . . . . 144 B.6.1. Descripci´on detallada . . . . . . . . . . . . . . . . . . 144 B.6.2. Documentaci´on de las funciones miembro . . . . . . . 145 B.7. Referencia de la Clase io::IOInterface . . . . . . . . . . . . . . 149 B.7.1. Descripci´on detallada . . . . . . . . . . . . . . . . . . 150 B.7.2. Documentaci´on de las funciones miembro . . . . . . . 150 C. Licencias 161 C.1. GNU General Public License . . . . . . . . . . . . . . . . . . 163 C.2. GNU Free Documentation License . . . . . . . . . . . . . . . 178
  9. 9. ´Indice de figuras 3.1. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . 29 3.2. Diagrama de Clases . . . . . . . . . . . . . . . . . . . . . . . 32 3.3. Diagrama de Secuencia: Generar Medici´on . . . . . . . . . . . 35 3.4. Diagrama de Secuencia: Cargar Medici´on . . . . . . . . . . . 38 3.5. Ejemplo de Fichero CSV: Una medici´on . . . . . . . . . . . . 41 3.6. Ejemplo de Fichero CSV: Tres mediciones . . . . . . . . . . . 42 3.7. Cuantos de tiempo en el planificador de Linux . . . . . . . . . 44 3.8. Estructura de Componentes de Karma GNU/Linux . . . . . . 45 3.9. Posicionamiento de ADEOS en el sistema operativo . . . . . 46 3.10. Composici´on RTAI y Linux . . . . . . . . . . . . . . . . . . . 48 3.11. Arquitectura del sistema PAPI . . . . . . . . . . . . . . . . . 53 4.1. Glperfex: ventana principal . . . . . . . . . . . . . . . . . . . 70 4.2. Glperfex: pesta˜na de contadores . . . . . . . . . . . . . . . . . 71 4.3. Glperfex: pesta˜na de resultados con siete ejecuciones . . . . . 72 4.4. Glperfex: pesta˜na de resultados con una ejecuci´on . . . . . . 73 4.5. Glperfex: opciones del men´u archivo . . . . . . . . . . . . . . 74 4.6. Glperfex: abriendo una prueba . . . . . . . . . . . . . . . . . 75 4.7. Glperfex: resultados cargados de un fichero CSV . . . . . . . 76 A.1. Manual de Usuario: abrir glperfex . . . . . . . . . . . . . . . . 106 A.2. Manual de Usuario: Medici´on con Planificador Est´andar . . . 107 A.3. Manual de Usuario: Medici´on con Planificador Est´andar . . . 108 A.4. Manual de Usuario: Medici´on con Planificador Est´andar 1 . . 111 A.5. Manual de Usuario: Resultados con Planificador Est´andar 2 . 112 A.6. Manual de Usuario: Ejecuci´on en Modo Exclusivo . . . . . . . 113 A.7. Manual de Usuario: Men´u Archivo . . . . . . . . . . . . . . . 114 vii
  10. 10. ´Indice de cuadros 3.1. Plantilla para la Definici´on de Casos de Uso . . . . . . . . . . 30 3.2. Ejemplo de Fichero CSV resultado de una medici´on . . . . . 40 3.3. Ejemplo de Fichero CSV resultado de tres mediciones . . . . 40 4.1. Configuraci´on del Entorno en Tiempo Real . . . . . . . . . . 61 4.2. Configuraci´on de perfctr dentro del kernel de Linux . . . . . . 62 4.3. Configuraci´on previa del kernel del Live CD . . . . . . . . . . 76 5.1. Resultados de las mediciones est´andar sin ruido . . . . . . . . 88 5.2. Resultados obtenidos para las pruebas est´andar con ruido . . 90 5.3. Resultados de las mediciones bajo entorno exclusivo . . . . . 91 A.1. Manual de Usuario: caracter´ısticas v´alidas de un ejecutable . 107 ix
  11. 11. Cap´ıtulo 1 Introducci´on En ciertas ocasiones, la ejecuci´on de programas se ve condicionada por la necesidad de una respuesta instant´anea. Un ejemplo de ello puede encon- trarse en programas que supervisan la din´amica de un sistema f´ısico, como el control de inyecci´on de combustible de un motor, que debe realizar la mezcla en un intervalo de tiempo determinado. A este tipo de computaci´on se le denomina computaci´on en tiempo real. Karma Linux es una distribuci´on de GNU/Linux en tiempo real dise˜nada para la medici´on de eventos de procesador. En nuestro caso, las exigencias de tiempo real vienen dadas por la necesidad de ejecutar programas en un procesador de manera que la medici´on de su ejecuci´on se vea condicionada por la menor cantidad posible de ruido, es decir, que el proceso lanzado pueda ejecutarse de forma exclusiva sobre el procesador, obteniendo as´ı el mayor rendimiento. En los ´ultimos a˜nos, los objetivos en el dise˜no de procesadores ha cam- biado radicalmente. La b´usqueda de la m´axima frecuencia, del mayor rendi- miento para un solo procesador se ha visto desbordada por el viejo concepto de la computaci´on paralela, estamos en la era de los multicore. La primera versi´on de Karma Linux fue desarrollada en septiembre de 2006 como proyecto fin de carrera del alumno de Ingenier´ıa T´ecnica en Inform´atica de Sistemas Pedro Navajas Modelo [1] bajo la direcci´on de Ezequiel Herruzo G´omez, profesor del Departamento de Arquitectura de Computadores, Electr´onica y Tecnolog´ıa Electr´onica. Esta primera versi´on estaba dise˜nada para la ejecuci´on en sistemas monoprocesador de la arquitectura x86, lo que implicaba que los programas ejecutados en Karma no pudieran aprovechar la capacidad de todas las tecnolog´ıas emergentes en paralelizaci´on de carga de procesador. Ejemplos de estas tecnolog´ıas podemos encontrar en HyperThreading de Intel (que simula dos 1
  12. 12. 2 1.1. Eventos del Procesador procesadores l´ogicos dentro de un ´unico procesador f´ısico, lo que supone una mejora en el uso del procesador de un 30 % [3]) implementado en algunos modelos de Pentium IV o en los casi ´ultimos procesadores de Intel, los Dual Core y Core 2 Duo. Por este motivo surgi´o la motivaci´on de realizar una nueva versi´on de Karma, que pudiese lograr ejecuciones ´optimas en estos ´ultimos procesadores, haciendo hincapi´e tambi´en en un dise˜no intuitivo de la aplicaci´on, de manera que pudiera ser utilizada f´acilmente con fines docentes. A continuaci´on vamos a realizar un enfoque de los conceptos necesarios para abordar la tarea. En el primer p´arrafo se defin´ıa a Karma Linux como una distribuci´on en tiempo real para la medici´on de eventos de procesa- dor. Por ello, en la introducci´on al proyecto es necesario definir estos dos conceptos que confluyen e introducir as´ı al lector de lleno en la tem´atica del mismo, de manera que la lectura de los subsiguientes cap´ıtulos sea lo m´as sencilla posible. En primer lugar haremos un enfoque sobre los even- tos del procesador, para mostrar c´omo se miden estos eventos a trav´es de contadores hardware que proporcionan los procesadores, y en segundo lugar realizaremos una introducci´on a los sistemas operativos en tiempo real y los conceptos fundamentales para la comprensi´on de los mismos. 1.1. Eventos del Procesador Los eventos del procesador son todas las operaciones at´omicas produci- das dentro del mismo. Nos referimos con at´omicas a las operaciones que al dividirse pierden su condici´on. Por ejemplo, una instrucci´on de procesador es divisible, pero cada una de sus divisiones no forman una instrucci´on. Dichos eventos est´an asociados a uno o varios recursos hardware (de- pendiendo de la arquitectura y modelo de procesador) y nos servir´an para obtener informaci´on acerca de la ejecuci´on de procesos y su rendimiento. Los contadores de monitorizaci´on de rendimiento (Performance Monito- ring Counters o PMC) son contadores hardware inclu´ıdos en la mayor´ıa de procesadores existentes en el mercado. Estos contadores registran un gran n´umero de eventos relacionados con el rendimiento de una aplicaci´on duran- te la ejecuci´on, por ejemplo, el n´umero de instrucciones ejecutadas, fallos de cach´e o cualquier evento propio de la familia del procesador. El objetivo de los PMCs es identificar problemas de rendimiento a bajo nivel, de manera que sea posible solucionar futuros problemas en la puesta en marcha de pro- yectos sensibles a la optimizaci´on del uso del dispositivo sobre el que ser´an ejecutados.
  13. 13. Introducci´on 3 1.1.1. Perfctr y Performance API Linux Performance-Monitoring Counters Driver (Perfctr) es una biblio- teca desarrollada por Mikael Pettersson, profesor del Departamento de Tec- nolog´ıas de la Informaci´on de la Universidad de Uppsala, que modifica el kernel de Linux para permitir el acceso a los contadores hardware de la m´aquina. El acceso a estos contadores se realiza a trav´es de un conjunto de PMCs virtuales accesibles desde el dispositivo /dev/perfctr, de esta ma- nera cada proceso pueda obtener, a trav´es de una llamada al sistema, los resutados de la medici´on de su ejecuci´on. La Performance Application Programming Interface (PAPI) es un pro- yecto desarrollado por el Departamento de Ingenier´ıa El´ectrica y Ciencias de la Computaci´on de la Universidad de Tennessee que trata de especificar una interfaz de programaci´on est´andar para el acceso a los contadores hard- ware del procesador a trav´es del driver perfctr. Provee dos interfaces, una de alto nivel y f´acil uso, y otra completamente programable a bajo nivel para necesidades m´as espec´ıficas. PAPI presenta una gran portabilidad, un c´odigo escrito usando PAPI debe medir los mismos eventos en distintas plataforma sin la necesidad de realizar ning´un cambio. Por otro lado para el acceso a contadores espec´ıficos de una m´aquina simplemente habr´a que utilizar la interfaz de bajo nivel anteriormente mencionada. 1.1.2. Ruidos La mayor´ıa de sistemas operativos modernos de prop´osito general com- parten una caracter´ıstica fundamental, permiten la planificaci´on multitarea. Esto supone la necesidad de ejecuci´on de procesos sobre uno o varios proce- sadores al mismo tiempo, por lo que el sistema operativo necesita crear una concurrencia virtual entre dichos procesos, de forma que puedan convivir en el mismo entorno de forma transparente al usuario. El procedimiento que se sigue para conseguir el objetivo de la multitarea se basa en la asignaci´on de prioridades a los diferentes procesos, seg´un la cual el planificador del sistema crea una cola en la que de cada proceso activo se ejecutar´a un cuanto1 de determinado tama˜no (influido por la prioridad el proceso). Para evitar atascos en la ejecuci´on de tareas, el planificador contempla mecanismos de reemplazo, seg´un los cuales un proceso de mayor prioridad puede reemplazar la ejecuci´on de uno de menor prioridad. De acuerdo con las caracter´ısticas del planificador del kernel de Linux, 1 Tiempo que el proceso puede ejecutarse sin ser reemplazado.
  14. 14. 4 1.2. Sistemas Operativos en Tiempo Real si un proceso requiere 20000 ms de tiempo de procesador para llevar a cabo su ejecuci´on completa, dependiendo del uso y de la prioridad, el planificador lo dividir´a en cuantos de aproximadamente 100 ms y lo trasladar´a a la cola junto al resto de procesos activos. Cuando entre en competici´on un proceso de mayor prioridad, es pro- bable que ´este reemplace a nuestro proceso aunque estuviera activo en ese momento de acuerdo con la capacidad de reemplazo del planificador. Esta caracter´ıstica de los sistemas operativos de prop´osito general difi- culta enormemente la capacidad de medir el tiempo que tarda el proceso en ejecutarse. Dependiendo de la carga del sistema, nuestro proceso, que re- quer´ıa 20000 ms, puede llegar a durar hasta m´as de 100000 ms, consumiendo un mayor n´umero de ciclos, provocando m´as fallos en memoria cach´e, etc. Esta intrusi´on de c´odigo de otros procesos es el concepto que de ahora en adelante llamaremos ruido, ya que provoca interferencias en la medici´on de eventos imposibles de predecir. 1.2. Sistemas Operativos en Tiempo Real Para comprender la diferencia en la ejecuci´on exclusiva de Karma Li- nux con las ejecuciones est´andar de Linux debemos diferenciar los Sistemas Operativos en tiempo real de los Sistemas Operativos convencionales. Una manera muy intuitiva de hacer esto es describir las caracter´ısticas de im- portancia que debe cumplir un Sistema Operativo y comentar las diferentes maneras de enfocarlas de los RTOS2 y los Sistemas Operativos de Prop´osito General. Estas caracter´ısticas principales son: planificaci´on de tareas, ma- nejo de interrupciones, sincronizaci´on y comunicaci´on y la gesti´on de la memoria. 1.2.1. Planificaci´on de tareas La planificaci´on de tareas o hilos es el principal problema de un sistema operativo. Mientras el sistema est´a en funcionamiento deben crearse y eli- minarse tareas, ´estas pueden cambiar su nivel de prioridad, necesidades de memoria, etc. En un sistema en tiempo real, estas tareas son m´as peligrosas que en un sistema operativo de prop´osito general: si se crea una tarea en tiempo real, debe obtener la memoria que requiera reservar sin demoras. Dicha memoria deber´a ser almacenada de manera que no se produzcan re- 2 Real Time Operating Systems, Sistemas Operativos en Tiempo Real
  15. 15. Introducci´on 5 trasos debidos a swapping3, por lo que los datos deber´ıan ser almacenados en memoria principal. Adem´as, cambiar la prioridad en la ejecuci´on de un proceso influir´ıa al comportamiento de toda la ejecuci´on del sistema, y el determinismo del mismo, que es una caracter´ıstica de gran importancia en un Sistema Operativo en Tiempo Real. Por ello la planificaci´on de tareas es uno de los principales rompecabezas en los RTOS. Normalmente, sobre un sistema multitarea, existen m´ultiples tareas acti- vas al mismo tiempo, y el sistema operativo es responsable de suministrar de manera compartida los recursos disponibles, es decir, tiempo de CPU, me- moria, etc. A la decisi´on del sistema operativo sobre la manera de compartir los procesadores se le denomina planificaci´on. Para la planificaci´on existen una serie de algoritmos, valorados en funci´on de su eficiencia y simpleza, su optimalidad. En los Sistemas Operativos en Tiempo Real se tiende a utilizar algoritmos de planificaci´on simples, ya que se necesita un tiempo de computaci´on peque˜no y determin´ıstico, debemos apostar por soluciones que se consuman la menor cantidad de memoria. En los Sistemas Operativos de prop´osito general, la pol´ıtica de planifi- caci´on difiere en gran medida, se tienen en cuenta los mismos principios, sin embargo en estos sistemas se pretende obtener un rendimiento ´optimo en valores medios, mientras que en los RTOS se requiere un comportamiento determinista. 1.2.2. Manejo de Interrupciones Un sistema operativo debe ser capaz, adem´as de capaz de planificar tareas de acuerdo con un algoritmo determinista, de proporcionar acceso a dispositivos perif´ericos como motores, sensores, contadores de tiempo, discos externos, etc. Esto requiere una atenci´on del sistema operativo de manera as´ıncrona, cuando el proceso en ejecuci´on requiere esos servicios, el sistema operativo debe comprobar que est´a listo para complacer los requerimientos, estas llamadas al sistema se denominan interrupciones. Existen dos tipos de interrupciones: Interrupciones de hardware El perif´erico pone un bit en un canal par- ticular, que comunica al procesador en el cual se ejecuta el sistema operativo que necesita ser servido. Como resultado de esto, el proce- 3 Se denomina swapping al modo de interrelacionar la memoria principal (que contiene el programa en ejecuci´on, proceso inmediato y resultados intermedios) con la secunda- ria, ampliando as´ı la capacidad de la memoria principal bas´andose en la capacidad del almacenamiento secundario.
  16. 16. 6 1.2. Sistemas Operativos en Tiempo Real sador almacena el estado actual y salta a la direcci´on en su espacio de memoria que ha sido conectada a la inicializaci´on de la interrupci´on. Interrupciones de software Muchos procesadores disponen de instruc- ciones equivalentes a las interrupciones de hardware generadas por software. El resultado tambi´en hace que se salte a una direcci´on de memoria especificada previamente. El sistema operativo no se involucra en principio en la ejecuci´on de el c´odigo que genera la interrupci´on del hardware, de esto se encarga el proce- sador sin que se vea interferido por ning´un software. Sin embargo, el sistema operativo tiene influencia, primero, en la conexi´on de la direcci´on de memo- ria con cada l´ınea de interrupci´on y segundo en los momentos posteriores a la interrupci´on. En los Sistemas Operativos en Tiempo Real, l´ogicamente, se debe proceder a un manejo de las interrupciones de manera que se garantice que las tareas son servidas de manera determinista. 1.2.3. Comunicaci´on y Sincronizaci´on La tercera responsabilidad de un sistema operativo es conocida como co- municaci´on entre procesos (Inter-Process Communication o IPC). La IPC comprende una extensa cantidad de primitivas de programaci´on que el sis- tema operativo ofrece para la necesidad de intercambio de informaci´on con otras tareas y/o la sincronizaci´on en sus acciones. En los RTOS, debe obte- nerse una comunicaci´on y sincronizaci´on de manera determinista. Hay que recordar que la comunicaci´on y sincronizaci´on con otras tareas no se limita simplemente a aquellas que son ejecutadas en la misma m´aqui- na, sino que pueden aplicase tambi´en a la necesidad de comunicaci´on entre perif´ericos o dispositivos en red. 1.2.4. Gesti´on de la memoria La cuarta responsabilidad de un sistema operativo es la gesti´on de me- moria. Los diferentes procesos en el sistema requieren una parte de la memoria disponible. En ocasiones, esta memoria debe estar almacenada en una direcci´on espec´ıfica. Por lo tanto, el trabajo del sistema operativo es dar a cada proceso la memoria que necesita, memory allocation, realizar el mapeo de memoria real en los diferentes rangos de direcciones usadas por las tareas que requieren la memoria, memory mapping, y realizar la acci´on apropiada
  17. 17. Introducci´on 7 cuando una tarea utiliza memoria que no ha sido reservada4. A esto se le llama tambi´en protecci´on de memoria, que en ocasiones suele solucionarse simplemente matando el proceso que ha pedido el acceso no autorizado. Una vez introducidos los conceptos necesarios para comprender los di- ferentes conceptos en los que se basa la definici´on, dise˜no y soluci´on del proyecto, podemos comenzar el proceso de desarrollo del mismo. El estudio de dichos conceptos en las diferentes asignaturas que compo- nen el plan de estudios de la titulaci´on de Ingeniero T´ecnico en Inform´atica de Sistemas no cumple con los requisitos adecuados para la comprensi´on del mismo. Por ello, hemos considerado necesaria una introducci´on profunda en la materia, de manera que el alumno, o cualquier lector interesado en re- tomar el proyecto o simplemente estudiarlo, pueda inmiscuirse en el mismo desde el comienzo, con una curva de aprendizaje pronunciada al inicio pero m´as suave a medida que se avanza en la lectura. 4 Causas comunes de esto son punteros no conectados, o utilizaci´on de valores fuera de un array reservado.
  18. 18. Cap´ıtulo 2 Definici´on del Problema 2.1. Identificaci´on del Problema Real La informaci´on acerca del rendimiento es crucial en el desarrollo de cual- quier proyecto software. Los recursos inform´aticos reales no son infinitos, y este problema se convierte en excesivamente cr´ıtico si estamos tratando con sistemas empotrados y en definitiva toda clase de sistemas en tiempo real, donde la optimizaci´on de c´odigo debe enfocarse hacia el objetivo de una ejecuci´on r´apida que realice el menor n´umero de ciclos de procesador posible. Para obtener toda esa informaci´on en la ejecuci´on de un programa, son necesarias herramientas de detecci´on que nos proporcionen una interfaz con las capacidades de medici´on que ofrece el procesador sobre datos como ciclos de ejecuci´on, accesos o fallos de cach´e. El proceso de medici´on de cualquier magnitud debe entra˜nar la m´axima exactitud posible. En el caso que nos ocupa, la medici´on de eventos de procesador viene marcada por la condici´on de “convivencia” de procesos en un sistema operativo enfocado a la ejecuci´on concurrente de programas. Esta ejecuci´on en convivencia, puede provocar mediciones con un exceso evidente de ruido que nos lleve a conclusiones err´oneas a la hora de enfocar el dise˜no de nuestro programa si consideramos estas mediciones como propias de un contexto determinista1. Adem´as de controlar la fiabilidad de la medici´on, a la hora de la realiza- ci´on de pruebas es necesario mantener el enfoque de portabilidad del sistema, es decir, debemos ofrecer la capacidad de ejecutar las pruebas en el mayor 1 Un contexto determinista en este caso se trata de aquel entorno donde se obtiene el mismo resultado bajo unas condiciones iniciales similares. 9
  19. 19. 10 2.2. Identificaci´on del Problema T´ecnico n´umero de entornos posible. De esta manera, el dise˜no de nuestro sistema de pruebas no puede ce˜nirse a dispositivos monoprocesador, sino que debemos dar un paso adelante y permitir la entrada de la tecnolog´ıa emergente de procesadores multin´ucleo2, permitiendo aislar ejecuciones determin´ısticas en m´as de un n´ucleo o procesador. Por ´ultimo, el proceso de medici´on debe ser transparente al usuario, y a ser posible, lo m´as intuitivo posible. Esto hace necesario un entorno donde no sea necesario recompilar el c´odigo para lanzar ejecuciones, donde todos los elementos para la medici´on est´en ya disponibles, sin necesidad de instalar software adicional, y donde la facilidad de uso mediante una interfaz sencilla lleven a la persona encargada de realizar las pruebas al objetivo inicial de optimizaci´on del programa en un entorno fiable y, a pesar de no tratarse de una expresi´on de nuestro gusto, amigable. 2.2. Identificaci´on del Problema T´ecnico A continuaci´on se presentan los aspectos t´ecnicos relevantes a la hora de llevar a cabo la identificaci´on del problema t´ecnico haciendo uso de la t´ecnica de Especificaciones del Dise˜no del Producto (Product Design Specification o PDS), que nos permite realizar un an´alisis de los principales condicionantes t´ecnicos respondiendo a los siguientes apartados. 2.2.1. Funcionamiento El proyecto consta de cuatro apartados fundamentales definidos a con- tinuaci´on: lperfex Es la aplicaci´on encargada de realizar mediciones de procesador de cualquier tarea. lperfex dispone de una interfaz gr´afica llamada glperfex que incrementa las posibilidades de esa interfaz permitiendo extraer y guardar datos y gr´aficas de dichas ejecuciones. El funcionamiento de lperfex no es intrusivo, ya que realiza un proceso v´ırico (intercepta el inicio del proceso, colocando c´odigo al inicio y al fin con el objetivo de preparar y recoger los resultados de ejecuci´on del programa). 2 En la redacci´on del manual t´ecnico se utilizar´an indistintamente los conceptos de multin´ucleo, su equivalente en ingl´es multicore y multiprocesador para referirnos a la ejecuci´on de procesos del sistema operativo en m´aquinas con m´as de un procesador, ya sea real o virtual.
  20. 20. Definici´on del Problema 11 Dicho programa puede, por lo tanto, haber sido escrito en C, Fortran o cualquier lenguaje que permita generar un fichero ejecutable que cum- pla con los est´andares comentados en el apartado 2.2.7, dependiendo la medici´on simplemente de la existencia de un binario a ejecutar, faci- litando as´ı el proceso al usuario, que no deber´a recompilar el programa para realizar las pruebas. RTAI Como se describi´o en la identificaci´on del problema real, debe existir un elemento que permita la ejecuci´on del proceso a medir de forma independiente al planificador del kernel de Linux. Para realizar estas mediciones ser´a necesaria la utilizaci´on de una herramienta que se coloque por encima del propio n´ucleo, eludiendo as´ı los cambios de contexto provocados por las interrupciones software, el reemplazo en la cola de planificaci´on, etc. La herramienta que permite esta capacidad es el proyecto RTAI, que ofrece a nuestro sistema la capacidad de realizar operaciones en tiempo real. PAPI Este es el elemento en el que se basa lperfex para acceder a los contadores hardware que el usuario desee medir. Haciendo uso del driver perfctr, PAPI permite al programador me- diante una biblioteca sencilla y portable realizar mediciones de esos contadores. Live CD La aplicaci´on lperfex necesita un entorno de ejecuci´on que dispon- ga de unas caracter´ısticas especiales. Necesita acceso a los contadores hardware que ofrece el procesador para obtener las estad´ısticas soli- citadas de cada ejecuci´on as´ı como las caracter´ısticas de tiempo real que coment´abamos en la descripci´on de RTAI. Para ello es necesaria la instalaci´on de parches al kernel de Linux y carga de varios m´odu- los as´ı como la instalaci´on de varias bibliotecas. Para evitar la tediosa operaci´on de instalar todos los componentes en un sistema, la opci´on m´as sencilla es presentar todo el sistema empaquetado en un Live CD con herramientas b´asicas como un entorno gr´afico, navegador web, he- rramientas de oficina, desarrollo, etc. 2.2.2. Entorno Como se adelant´o a la hora de definir el funcionamiento, el entorno de ejecuci´on de nuestro sistema se forma en un Live CD. Un Live CD forma un sistema operativo ejecutado al arrancar la m´aqui- na sin realizar ninguna instalaci´on en el disco duro. Contiene una imagen
  21. 21. 12 2.2. Identificaci´on del Problema T´ecnico comprimida del sistema, en este caso con todas las caracter´ısticas requeri- das. Una vez arrancado, descomprime el sistema de ficheros del CDROM (squashfs) y comienza el arranque. Una de las caracter´ısticas de los Live CD es que adaptan la configuraci´on del sistema a la m´aquina sobre la que se est´an ejecutando. De esta manera, se detectar´an los dispositivos de los que dispone la misma y los configurar´a correctamente para el trabajo a realizar. Una vez cargada la configuraci´on y arrancado el sistema, nos encontrare- mos con el entorno tal y como fue dise˜nado para su uso. El kernel del sistema operativo, convenientemente parcheado, habr´a cargado los m´odulos necesa- rios tanto para la ejecuci´on exclusiva de tareas cuando esta sea requerida, como para acceder correctamente a los contadores hardware. La principal novedad de Karma Linux 2008, adem´as de la posibilidad de aislar en los procesadores deseados la carga del programa a ejecutar es la incorporaci´on de la interfaz gr´afica glperfex para realizar las mediciones. De esta manera, adem´as de facilitar el trabajo con nuevas opciones para el usuario, se pretende que la aplicaci´on pueda ser utilizada de forma sencilla con fines docentes, donde los alumnos no se tendr´an que enfrentar al impe- dimento de no tener un alto conocimiento de interacci´on con la terminal del sistema (modo de interacci´on original de lperfex). Por ello, con estas facili- dades, el entorno de ejecuci´on de la aplicaci´on se hace plenamente accesible sin necesidad de configuraci´on ni grandes conocimientos previos. No obstante, Karma sigue ofreciendo la capacidad de utilizar lperfex sin necesidad de interfaz gr´afica, mediante la interacci´on est´andar por consola de getopts. 2.2.3. Vida Esperada La capacidad de adaptaci´on a la medici´on de ejecuci´on, y a las carac- ter´ısticas de cualquier sistema (siempre teniendo en cuenta la arquitectura x86 para la que ha sido dise˜nada la distribuci´on) mediante la detecci´on de dispositivos, hace que el proyecto pueda seguir cubriendo las necesidades para las que se dise˜na a lo largo del tiempo. 2.2.4. Ciclo de Mantenimiento Karma est´a compuesto de una serie de herramientas libres, cuyo desarro- llo se lleva a cabo por una comunidad muy activa. Si se examinan art´ıculos provistos tanto en la p´agina web de RTAI [6] o en la de PAPI [7] existen una gran cantidad de proyectos afectados por el desarrollo de dichas bibliotecas,
  22. 22. Definici´on del Problema 13 que cada d´ıa ampl´ıan su soporte a nuevas arquitecturas o familias de proce- sadores. Este hecho hace que el futuro mantenimiento de Karma ampl´ıe los horizontes para los que ha sido dise˜nado de manera que se cubran nuevos procesadores y se adapte a la medici´on real en todo tipo de entornos. El dise˜no modular del sistema, hace posible la actualizaci´on sencilla de com- ponentes, de manera que el proyecto no ser´a dif´ıcil de retomar en futuras versiones. 2.2.5. Competencia La competencia a la aplicaci´on, tal y como se describir´a en el apartado 2.4 es escasa, existen escasos antecedentes que se puedan ajustar a las ca- racter´ısticas requeridas a la hora de concebir el proyecto y en caso de existir son obsoletos. 2.2.6. Aspecto Externo Como se ha comentado a lo largo del apartado 2.2, el aspecto externo ser´a el Live CD desde el que se ejecutar´a la aplicaci´on de medici´on. Este englobar´a la aplicaci´on lperfex y sus dependencias, incluyendo las bibliotecas encargadas de interceptar tareas y a˜nadir c´odigo al principio y final de las tareas interceptadas. La interfaz gr´afica lperfex ser´a dise˜nada usando el binding3 de la bibliote- ca gr´afica wxWidgets para el lenguaje de programaci´on Python, wxPython. Esta biblioteca se caracteriza por ser multiplataforma, por lo que su uso junto a Python permite el desarrollo r´apido de aplicaciones gr´aficas multi- plataforma. Puesto que ´esta se trata no se trata de una aplicaci´on de ´ambito comer- cial, las caracter´ısticas de presentaci´on y distribuci´on del soporte del sistema no se tendr´an en cuenta. 2.2.7. Estandarizaci´on El desarrollo de un proyecto software libre requiere un ´enfasis en la estan- darizaci´on del sistema, de manera que los potenciales desarrolladores puedan realizar futuros cambios y modificaciones de forma que se fomente la mejora del proyecto. 3 En el campo de la programaci´on, un binding es una adaptaci´on de una biblioteca para ser usada en un lenguaje de programaci´on distinto de aqu´el en el que ha sido escrita.
  23. 23. 14 2.2. Identificaci´on del Problema T´ecnico La distribuci´on sigue las indicaciones de la Linux Standard Base (LSB), con la salvedad del uso, impl´ıcito en distribuciones de tipo Debian, de empaquetado deb en lugar de rpm [8]. Esta excepci´on se podr´ıa salvar utilizando el programa alien en el empaquetado. Se pue- den consultar cr´ıticas sobre esta normativa en [9] y [10]. Las mediciones s´olo ser´an admitidas para ficheros ejecutables que sigan el formato de enlazado ELF4. Adem´as para el uso de lperfex por terminal se utilizar´a el est´andar definido por la GNU Libc getopts adem´as de utilizar las herramientas de edici´on de proyectos autotools. A la hora de desarrollar la interfaz gr´afica, el enfoque se dirige a Python en su versi´on 2.4, para guardar compatibilidades, mientras que por con respecto a wxPython se utilizar´an caracter´ısticas de la versi´on de 2.8 debido a las numerosas mejoras que presenta frente a versiones anteriores. 2.2.8. Calidad y Fiabilidad La calidad y fiabilidad del producto final ser´an evaluadas comprobando la mejora del sistema mediante tests realizados en caracter´ısticas norma- les de uso y los tests realizados aislando los procesos en los procesadores especificados en la prueba. Midiendo tambi´en la diferencia entre entornos con ruido y entornos sin ruido que demuestren la calidad y precisi´on de la soluci´on final. 2.2.9. Programa de Tareas A diferencia de la primera versi´on de Karma, el proyecto fin de carrera parte de una soluci´on dada y pretende una mejora de la misma. De esta manera, que la carga de investigaci´on del mismo se ha visto reducida sensi- blemente. Tambi´en debemos tener en cuenta que al tratarse de un proyecto fin de carrera, en principio, y adapt´andonos al caso que nos ocupa, no es necesario un c´alculo de costes o plazos de ejecuci´on. 4 El formato ELF (Executable and Linkable Format) es un formato de archivo para ejecutables, c´odigo objeto, librer´ıas compartidas y volcados de memoria. Fue desarrollado por el Unix System Laboratory (USL) como parte de la ABI. En principio fue desarrollado para plataformas de 32 bits, a pesar de que hoy en d´ıa se usa en gran variedad de sis- temas. Es el formato ejecutable usado mayoritariamente en los sistemas tipo Unix como GNU/Linux, BSD, Solaris, IRIX. Existen otros formatos soportados en algunos de estos sistemas como COFF o a.out, pero ELF es sin duda el m´as usado.
  24. 24. Definici´on del Problema 15 Las fases de desarrollo del proyecto ser´an: Fase de Preparaci´on Durante esta fase se reunir´a la informaci´on necesa- ria para abordar la realizaci´on del proyecto. Estudio de Karma Linux original en su conjunto desgranando los componentes. Estudio de la herramienta lperfex. Estudio de RTAI. Fase de Especificaci´on de Requisitos Durante esta etapa ha de reali- zarse una descripci´on del comportamiento del sistema y los objetos individuales que forman parte del mismo, analizando las condiciones que debe reunir el sistema final. Fase de Implementaci´on Como resultado de la fase de especificaci´on de requisitos se implementar´a la soluci´on final con los cambios y adiciones necesarias a Karma Linux. Fase de Pruebas Se analizar´an las mejoras realizadas con las condiciones iniciales planteadas respecto a la versi´on original de Karma Linux, de manera que en caso de ser positiva se construya una nueva versi´on de Karma Linux en un Live CD. Fase de Documentaci´on Se reunir´an los documentos generados en fases anteriores para la redacci´on de los documentos pertinentes. 2.2.10. Pruebas En la fase final del proyecto, como hemos visto en el apartado anterior, se someter´a al sistema a un conjunto de pruebas para comparar los resultados previos y poder extraer conclusiones de las mejoras. Adem´as de las pruebas propias de la mejora de la aplicaci´on, ser´an ne- cesarias pruebas de caja blanca durante la codificaci´on de las codificaciones y modificaciones de c´odigo. 2.2.11. Seguridad La seguridad del sistema est´a basada en la seguridad propia de los siste- mas tipo Unix. La cuenta de usuario del Live CD tiene una contrase˜na que impide el acceso al mismo desde fuera del ordenador. Es decir, el usuario
  25. 25. 16 2.3. Objetivos deber´a tener acceso f´ısico al mismo, o acceder por red conociendo el usuario y contrase˜na con protocolos como SSH. Por otro lado la aplicaci´on es software libre bajo licencia GNU GPL versi´on 3, esto quiere decir, que todo el c´odigo y la aplicaci´on estar´a dis- ponible para el desarrollo de cualquier desarrollador que desee mejorarlo o modificarlo. Por ello no existir´a ning´un m´etodo de protecci´on anticopia. 2.3. Objetivos Una vez identificado el problema real y t´ecnico se exponen los objetivos a alcanzar con el desarrollo del proyecto. Como hemos adelantado, Karma Linux 2008 se plantea como una actualizaci´on de Karma Linux que supla las carencias del mismo en materia de usabilidad y se adapte a los nuevos procesadores multin´ucleo. 2.3.1. Adaptaci´on de Karma a Procesadores Multin´ucleo Como se mencion´o en la introducci´on, la implantaci´on del procesadores multin´ucleo en el mercado es una realidad a d´ıa de hoy. El enfoque mono- procesador de Karma Linux hace que la distribuci´on no pueda aprovechar ni examinar las capacidades de estos nuevos sistemas. Por ello el primer objetivo a cumplir por el proyecto es habilitar la he- rramienta lperfex para la medici´on de ejecuciones exclusivas en multipro- cesador, de manera que el programa detecte el n´umero de procesadores de la m´aquina y permita elegir en qu´e procesador o procesadores realizar la medici´on. 2.3.2. Mejora de la Usabilidad Una de las posibles ´areas de aplicaci´on de Karma Linux es la docencia. La medici´on de eventos de procesador al ejecutar un programa nos permite observar la mejora de esa ejecuci´on en distintos procesadores y programas, siendo informaci´on ´util para la comprensi´on de materias relacionadas con Sistemas Operativos y Arquitectura de Computadores. lperfex es, como hemos comentado anteriormente, una aplicaci´on acce- sible s´olo a trav´es de terminal mediante la interfaz de uso getopts. Esto dificulta la interacci´on con el mismo para un usuario inexperto adem´as de
  26. 26. Definici´on del Problema 17 limitar la informaci´on expuesta al no poder a˜nadir, por ejemplo, gr´aficas para ilustrar la ejecuci´on. Por ello, otro de los objetivos del proyecto es dotar a lperfex de una in- terfaz sencilla capaz de mostrar los resultados correctamente, a˜nadir gr´aficas al mismo y ofrecer la capacidad de almacenar los resultados para posteriores visualizaciones y comparaciones de forma compatible con programas tales como hojas de c´alculo, etc. A partir de ahora nos referiremos a esta interfaz como glperfex. 2.3.3. Autonom´ıa de la Plataforma El objetivo de garantizar la autonom´ıa de la plataforma hereda del plan- teamiento de Karma Linux original. Debido a la necesidad de un entorno especial en el que el planificador permita un mayor control sobre el procesa- dor y la cola de procesos, de manera que podamos garantizar la ausencia de ruidos externos en la ejecuci´on del programa a medir, ser´a necesario crear una plataforma donde la aplicaci´on y el entorno puedan existir de forma aut´onoma, proveyendo al usuario todas las herramientas necesarias para el desarrollo de su tarea. Esto conlleva: La construcci´on de un sistema comprimido en una imagen grabable a un CDROM con todas las bibliotecas, m´odulos y parches necesarios para la ejecuci´on de nuestro entorno. Autodetecci´on de hardware durante el arranque de la imagen del siste- ma, de manera que se generen los ficheros de configuraci´on necesarios para la ejecuci´on del mismo en cualquier m´aquina de la arquitectura x86 y x86 64. Construcci´on de paquetes adicionales para mejorar la usabilidad del sistema, esto significa incluir navegadores web, hojas de c´alculo, com- piladores y un entorno gr´afico. 2.4. Antecedentes A continuaci´on se presentan los antecedentes al proyecto a realizar, di- vidimos estos antecedentes en cuatro apartados. En primer lugar aquellas aplicaciones o interfaces de programaci´on para evaluar el funcionamiento de programas accediendo a contadores hardware, en segundo lugar los sistemas operativos o modificaciones que permitan la ejecuci´on de modo exclusivo de procesos, en tercer lugar analizaremos el antecedente de la distribuci´on y
  27. 27. 18 2.4. Antecedentes punto de partida principal del proyecto, Karma Linux, y por ´ultimo comenta- remos algunas soluciones posibles para realizar tests destinados a comprobar las mejoras que ofrece nuestro sistema. 2.4.1. Antecedentes a Lperfex y Glperfex ContEven Proyecto Fin de Carrera de Antonio Espinar Ruiz para el an´ali- sis de rendimiento de procesadores de tipo Pentium y AMD desarrolla- do en el ´Area de Arquitectura de Computadores del Departamento de Arquitectura de Computadores, Electr´onica y Tecnolog´ıa Electr´onica de la Universidad de C´ordoba en 2003. El inconveniente fundamen- tal que no hace aplicable el proyecto como soluci´on es que ´este s´olo muestra informaci´on gen´erica del procesador sin aprovechar la infor- maci´on que nos proporcionan los contadores hardware del procesador. Este programa funciona en la plataforma Windows, lo que traiciona nuestro objetivo moral de aportar una soluci´on utilizando ´unicamente software libre a la hora de enfocar el proyecto. Perfex Herramienta para la realizaci´on de tests en sistemas con procesador R10K y sistema operativo IRIX de Silicon Graphics a trav´es de los contadores de eventos proporcionados por dichos procesadores. Por ello se trata de una aplicaci´on imposible de adaptar a sistemas distintos para los que est´a concebido. SpeedShop Es un conjunto de herramientas para la ejecuci´on de prue- bas de rendimiento en programas ejecutables y examinar los resul- tados de dichas pruebas. Proporciona no s´olo las estad´ısticas t´ıpi- cas de programas de an´alisis de rendimiento de procesador como uso del procesador, estado de la pila o registro de excepciones, sino que adem´as, incorpora experimentos que que permiten analizar directa- mente el rendimiento de la memoria cach´e, fallos de acceso a memoria cach´e de datos e instrucciones, fallos de acceso a TLB5, controles como fork, exec, sproc, etc. Sin embargo al igual que Perfex, SpeedShop s´olo puede ser utilizado en sistemas IRIX. Papiex Sistema similar a la herramienta Perfex para entornos x86. Esta aplicaci´on se distribuye junto a PAPI y es ´util para el estudio de la intercepci´on de procesos. Sin embargo no ser´ıa soluci´on a nuestros objetivos al no permitir una ejecuci´on exclusiva del proceso sobre el procesador, adem´as de ser una herramienta poco actualizada [1]. 5 Translation Lookaside Buffer (TLB) es un b´ufer o cach´e en una Unidad de Procesa- miento Central (CPU), que contiene partes de la tabla de paginaci´on, es decir, relaciones entre direcciones virtuales y reales.
  28. 28. Definici´on del Problema 19 Intel Vtune Analiza el rendimiento de programas para Windows y Linux. Est´a dise˜nado para desarrollar software m´as eficiente y r´apido en sis- temas mono y multiprocesador. Adem´as, analiza aplicaciones sin ne- cesidad de recompilaci´on o enlazado [11]. Sin embargo, VTune est´a di- se˜nado exclusivamente para procesadores Intel, y el coste de su licencia es elevado. 2.4.2. Antecedentes de Planificadores en Tiempo Real RTLinux Es un sistema operativo en tiempo real utilizado en proyectos de medicina o aeron´autica [12]. Su vertiente de c´odigo abierto ha ca´ıdo en desuso [13] y la versi´on comercial es descartada por su car´acter privativo por las mismas razones que argument´abamos al hablar de ContEven. RTAI Es un sistema de tiempo real que utiliza una capa de abstracci´on llamada ADEOS y soporta arquitecturas como x86, PowerPC, ARM y MIPS [14]. El proyecto RTAI es software libre y se utiliz´o para para la planificaci´on de procesos de modo exclusivo en Karma Linux, nuestro antecedente principal. 2.4.3. Antecedentes de la Distribuci´on Karma Linux Es una distribuci´on de Linux en tiempo real para la me- dici´on de eventos [1]. Karma Linux est´a enfocado como adelantamos en la introducci´on en el uso del modo exclusivo de ejecuci´on sobre un ´unico procesador para los eventos que la requieran. La limitaci´on fun- damental de Karma Linux radica en este hecho, que impide un funcio- namiento ´optimo en sistemas multiprocesador. Adem´as, la aplicaci´on utilizada para la medici´on de contadores hardware carece de interfaz de usuario m´as all´a de la terminal. Con la realizaci´on de este proyecto pretendemos solventar estas dos limitaciones de Karma Linux. 2.4.4. Antecedentes a Sistemas de Benchmarking El benchmark es una t´ecnica utilizada para medir el rendimiento de un sistema o componente de un sistema, frecuentemente en comparaci´on con el cual se refiere espec´ıficamente a la acci´on de ejecutar un benchmark. La palabra benchmark es un anglicismo traducible al castellano como compa- rativa. Si bien tambi´en puede encontrarse esta palabra haciendo referencia al significado original en la lengua anglosajona, es en el campo inform´atico
  29. 29. 20 2.4. Antecedentes donde su uso est´a m´as ampliamente extendido. M´as formalmente puede en- tenderse que un benchmark es el resultado de la ejecuci´on de un programa inform´atico o un conjunto de programas en una m´aquina, con el objetivo de estimar el rendimiento de un elemento concreto, o la totalidad de la misma, y poder comparar los resultados con m´aquinas similares [15]. Los benchmarks analizados fueron: Standard Performance Evaluation Corporation (SPEC) Es un con- sorcio sin fines de lucro que incluye a vendedores de computadoras, integradores de sistemas, universidades, grupos de investigaci´on, pu- blicadores y consultores de todo el mundo. Son los responsables del conjunto de tests SPEC CPU2000, un benchmark creado con el fin de proveer una medida de rendimiento que pueda ser usado para com- parar cargas de trabajo intensivas de c´omputo en distintos sistemas. Se divide en dos suites principales, la CINT2000, orientada a la medi- ci´on de computaci´on sobre enteros, y la CFP2000, para punto flotante. SPEC CPU2000 incluye algoritmos de teor´ıa de juegos e Inteligencia Artificial, recorrido de ´arboles, compiladores e int´erpretes, compresi´on de datos, bases de datos, predicci´on del clima, din´amica de fluidos, f´ısi- ca, qu´ımica y procesamiento de im´agenes, con lo que se puede probar un amplio espectro de algoritmia con dichos tests [16]. Los benchmarks SPEC fueron los elegidos para la realizaci´on de un art´ıculo sobre Kar- ma Linux presentado en el Congreso CEDI en 2005 [17]. NAS BenchMark Colecci´on de benchmark creados por la NASA. El pro- grama NAS naci´o como un gran esfuerzo por parte del centro de inves- tigaciones de la NASA para avanzar en el estudio de la computaci´on aerodin´amica. NAS presenta la ventaja de que al ser desarrollados con la computaci´on paralela en mente, son gen´ericos y no favorecen nin- guna m´aquina de forma espec´ıfica. Adem´as, a pesar de que la mayor´ıa de tests son de ejecuci´on paralela (usando MPI), tambi´en existe una rama que incluye los principales tests NAS en modo serial. El bench- mark NAS posee tres algoritmos principales, Lower-Upper Symmetric Gauss-Seidel (LUS), Scalar Penta-diagonal (SP) y Block Tri-diagonal (BT). Los test NAS cargan principalmente al procesador, teniendo escasa o nula presencia de entrada/salida [18]. Perfect Bencharmak Es una prueba orientada a superordenadores y pro- ceso en paralelo. Consta de 13 programas en FORTRAN, que incluyen aplicaciones de ingenier´ıa y cient´ıficas, representando a cuatro ´areas de estudio reales: mec´anica de fluidos, f´ısica y qu´ımica, dise˜no de inge- nier´ıa y procesado de se˜nal. Los resultados, expresados en millones de operaciones en coma flotante por segundo (MFLOPS), son calculados como la media geom´etrica de los resultados de este juego de tests [21].
  30. 30. Definici´on del Problema 21 2.5. Restricciones A continuaci´on se expondr´an las restricciones o factores limitativos exis- tentes en el ´ambito del dise˜no y que condicionan la elecci´on de las diferentes alternativas. 2.5.1. Factores Dato En el desarrollo del proyecto se considerar´an los siguientes factores dato: El resultado final ha de se transparente al usuario, esto implica que el usuario no tendr´a que realizar una configuraci´on previa del sistema y que la aplicaci´on a probar no requerir´a ser recompilada. Por lo tanto las mediciones se realizar´an sobre c´odigo compilado sin que el c´odigo de C, Fortran o cualquier lenguaje deba ser tratado de manera especial, siempre que haya sido compilado de acuerdo con el est´andar ELF. El sistema ha de ser multiplataforma, satisfaciendo as´ı el objetivo de crear un sistema aut´onomo e independiente de la plataforma donde se desee ejecutar (aunque no de la arquitectura). Adem´as deber´a ser capaz de aprovechar las tecnolog´ıas multiprocesador. Se har´a uso de la aplicaci´on lperfex y las bibliotecas RTAI y PAPI adoptando la soluci´on escogida en Karma Linux original para imple- mentar la medici´on no intrusiva de eventos. Esto implica que las fun- cionalidades a extender (no hablamos de proporcionar una interfaz gr´afica al programa, sino del funcionamiento interno del sistema de medici´on) deber´an programarse en C y deber´an cumplir con la licen- cia v´ırica GNU GPL v2 [19] de lperfex. Esto significa, que nuestra aplicaci´on ampliada, de acuerdo con la licencia GNU GPL, podr´a li- cenciarse como GPL v2 o superior, contando esta elecci´on como un factor estrat´egico. Uso de GNU/Linux, por motivos an´alogos al punto anterior, ya que este proyecto se plantea como una ampliaci´on de Karma Linux, todo deber´a enfocarse desde y para este sistema operativo. 2.5.2. Factores Estrat´egicos Tambi´en se considerar´an los siguientes factores estrat´egicos:
  31. 31. 22 2.5. Restricciones Enfoque del trabajo hacia la arquitectura x86, arquitectura de mayor uso y mayor facilidad de acceso a la hora de realizar el proyecto. Se podr´ıa realizar una versi´on de arquitectura x86 64, sin embargo esto impedir´ıa su aplicaci´on en la mayor´ıa de monoprocesadores comunes y en los Intel Core Duo (ordenadores a d´ıa de hoy utilizados en las aulas de inform´atica de la Universidad de C´ordoba). Uso de la licencia GNU GPL v3. Como se adelant´o en el tercer punto de los factores dato, lperfex, aplicaci´on que nos permitir´a realizar las mediciones de forma no intrusiva, ya sea usando un planificador en tiempo real o el planificador cl´asico del kernel de Linux, est´a licenciada seg´un la GNU GPL v2. Esta forma de licenciar el producto da la posibilidad de escoger en las modificaciones la licencia GNU GPL v2 o una licencia superior. En este caso se escoger´a la licencia GNU GPL v3 persiguiendo los objetivos de la misma en defensa del software libre [20]: • Resolver formas en que a pesar de todo alguien pod´ıa quitar li- bertades a los usuarios. • Como un caso especial de lo anterior: Prohibir el uso de softwa- re cubierto por licencias de sistemas dise˜nados para sustraer las libertades de los usuarios del mismo (como las tecnolog´ıas cono- cidas como DRM6). • Resolver ambig¨uedades y aumentar su compatibilidad con otras licencias. • Facilitar su adaptaci´on a otros pa´ıses. • Incluir cl´ausulas que defiendan a la comunidad de software libre del uso indebido de patentes de software. Realizaci´on de una interfaz gr´afica para la aplicaci´on lperfex de mo- do que se facilite la usabilidad del programa y que se proporcionen una serie de funcionalidades extra. Esto responde al inter´es de difun- dir la aplicaci´on entre personas sin un gran conocimiento del manejo de comandos bajo Unix. Desafortunadamente esto es com´un no s´olo entre alumnos de inform´atica sino tambi´en entre profesionales de la inform´atica. 6 Digital Rights Management (DRM) es un conjunto de tecnolog´ıas orientadas a ejercer restricciones sobre los usuarios de un sistema forzando de esta manera los derechos digitales permitidos por comisi´on de los poseedores de esos derechos de autor e independientemente de la voluntad del usuario/consumidor del mismo. Generalmente estos dispositivos son instalados como condici´on previa a la distribuci´on de software no libre, obras musicales, libros electr´onicos o cualquier tipo de archivo sujeto a derechos de autor. En algunos casos, las restricciones aplicadas se extienden m´as all´a de los archivos que deb´ıan proteger, agregando restricciones sobre el uso de otros documentos o aplicaciones presentes en la m´aquina.
  32. 32. Definici´on del Problema 23 Uso de Python para la realizaci´on de la interfaz gr´afica. Este factor estrat´egico se debe a la versatilidad del lenguaje, debida a la gran cantidad de bibliotecas que contiene, no s´olo para la realizaci´on de interfaces gr´aficas sino para manejo de cualquier tipo de dato, accesos al sistema, etc. Python nos ofrece una sencillez a la hora de programar que favore- cer´a tanto la rapidez del desarrollo de la interfaz, como la interacci´on con lperfex, gracias a la facilidad para operar con entradas y salidas de programas (stdin, stdout, stderr) o la posibilidad de realizar llamadas a funciones de C a trav´es de bindings. Con respecto a las pruebas de benchmarking se descartan los test Per- fect Benchrmark debido a que su antig¨uedad (los test son anteriores a 1985), hace que alguno de estos tests no sean compatibles con los compiladores modernos de Fortran. A pesar de su frecuente uso en el pasado, dichos test apenas se mencionan en documentos a partir del a˜no 2000 [1]. Los test escogidos para la realizaci´on del proyecto son los test NAS, cuyas caracter´ısticas resumimos en el apartado 2.4.4. Por ejemplo se usar´a un algoritmo para buscar la soluci´on de diferencias finitas a ecua- ciones de Navier-Stokes, que consisten en un conjunto de ecuaciones no lineales en derivadas parciales que describen el movimiento de un flui- do. Los dem´as tests tratan de resolver el mismo problema empleando diversos m´etodos matem´aticos [18]. La complejidad de c´alculo de los tests hace que provoquen una gran carga de procesamiento del sistema y una baja carga de entrada/salida, mejorando el m´etodo de medici´on de la mejora obtenida. Esta es la raz´on del descarte de los test SPEC como m´etodo de valoraci´on, ya que, a pesar de los buenos resultados obtenidos en experiencias previas, tienen una excesiva cantidad de entrada/salida. 2.6. Recursos para el Desarrollo A continuaci´on se comentar´an los recursos necesarios para el desarrollo del proyecto. Estos recursos vendr´an diferenciados en funci´on de su condi- ci´on, es decir, recursos humanos, hardware y software. 2.6.1. Recursos Humanos Los recursos humanos a la hora de desarrollar el proyecto son:
  33. 33. 24 2.6. Recursos para el Desarrollo Recursos humanos internos: Directores Prof. D. Ezequiel Herruzo G´omez y Prof. Dr. Jos´e Igna- cio Benavides Ben´ıtez, directores, asesoradores y supervisores del desarrollo del proyecto. Autor Fernando Garc´ıa Aranda. Encargado del an´alisis y soluci´on del problema, t´ecnicas de mejora, testeo y documentaci´on de la misma. Recursos humanos externos: Pedro Navajas Modelo Autor de Karma Linux. Lista de correo de RTAI Fundamental a la hora de examinar los puntos a modificar del programa para permitir la selecci´on de procesadores del multiprocesador que se desean utilizar en la eje- cuci´on exclusiva del programa. Lista de correo de PAPI Necesaria a la hora de conseguir que la soluci´on final se adapte a la medici´on de eventos en el m´aximo n´umero de procesadores (modelos) posibles. 2.6.2. Recursos Hardware Los recursos hardware a la hora de realizar el proyecto ser´an: Ordenador PC con procesador Intel Core 2 Duo (T7200), 2GHz, 4MB de memoria cach´e, 1GB de memoria RAM y 120GB de disco duro. Ser´a el utilizado para trabajar con multiprocesador, en este caso mul- ticore. Ordenador PC con procesador AMD Athlon XP 2.6Ghz, 512KB de memoria cach´e, 512MB de memoria RAM y 120GB de disco duro. Utilizado para trabajar en monoprocesador. 2.6.3. Recursos Software Los recursos software ser´an: Debian GNU/Linux: distribuci´on de GNU/Linux bajo la que se reali- zar´a el desarrollo de la soluci´on y que servir´a de base para la imple- mentaci´on final de la misma (Live CD).
  34. 34. Definici´on del Problema 25 Int´erprete de Python 2.4: para la ejecuci´on de la interfaz gr´afica de usuario. Biblioteca WxPython 2.8: binding de la biblioteca gr´afica wxWidgets (escrita en C++) para el lenguaje de programaci´on Python. Necesaria para la implementaci´on de la interfaz gr´afica de usuario. Live-helper: conjunto de paquetes para la creaci´on de Live CDs bajo Debian testing y unstable. Autotools: Herramientas para la creaci´on de proyectos de software libre que permite la generaci´on autom´atica de Makefiles adaptados a cada sistema, generaci´on y mantenimiento de traducciones, an´alisis de dependencias, etc. Colecci´on de Compiladores de GNU (GCC): Compiladores de C y For- tran empleados para compilar y enlazar el c´odigo fuente del medidor de eventos y las pruebas de testeo. Kernel de Linux: fuentes originales del kernel (vanilla sources) donde aplicaremos los parches necesarios, versi´on 2.6.22.15. Editores de textos Vim y Gedit, para la codificaci´on del proyecto y la documentaci´on del mismo. Kile: IDE7 de LATEX. DIA: programa para la realizaci´on de diagramas, procedimientos y gr´aficos de todo tipo necesarios para la documentaci´on del proyecto. Doxygen: generador de documentaci´on multilenguaje para el manual de c´odigo. Evince: programa para la visualizaci´on de documentos pdf y ps. Navegador web Iceweasel y cliente de correo Icedove (basados en las herramientas de Mozila Firefox y Thunderbird respectivamente, in- cluidos en Debian GNU/Linux). 2.7. Recursos para la Ejecuci´on A continuaci´on se comentar´an los recursos necesarios para la ejecuci´on del proyecto. 7 Integrated Development Environment, Entorno de Desarrollo Integrado.
  35. 35. 26 2.7. Recursos para la Ejecuci´on 2.7.1. Recursos Humanos Cualquier persona puede insertar el Live CD en su m´aquina e iniciar el sistema con las herramientas necesarias para realizar las mediciones. Este CD configurar´a el sistema y preparar´a todo lo necesario para que el usuario pueda realizar la labor sin necesidad de configurar nada. 2.7.2. Recursos Hardware Cualquier ordenador con arquitectura x86 o x86 64 y lector de DVD es suficiente para realizar las mediciones. 2.7.3. Recursos Software No es necesario ning´un recurso software, ya que el Live CD provee todos los recursos necesarios para crear un entorno de ejecuci´on id´oneo.
  36. 36. Cap´ıtulo 3 An´alisis del Sistema Si en cap´ıtulo anterior se ofreci´o una visi´on global del problema a resol- ver, describiendo as´ı la aplicaci´on a desarrollar, ahora es el momento de la especificaci´on t´ecnica de los requisitos de la aplicaci´on. Para describir la aplicaci´on glperfex, interfaz sencilla a lperfex utilizare- mos el Lenguaje Unificado de Modelado (UML) a trav´es de diagramas de casos de uso y clases, para el modelado est´atico, y diagramas secuencia, para el modelado din´amico. Por otro lado estableceremos los requisitos y espe- cificaciones del resto de los elementos que componen el sistema, adem´as de describir c´omo se alamacenar´a la informaci´on manejada. 3.1. Identificaci´on de Requisitos El proyecto trata de realizar un entorno sencillo y determinista de me- dici´on de eventos de procesador sobre programas ejecutables. A continuaci´on se presenta una lista general de requisitos del sistema, dada por los objetivos que enumeramos durante la etapa de definici´on del problema. Mejorar la precisi´on de las mediciones Esta propuesta requiere prue- bas en diversos entornos para solventar los aspectos del problema, por lo que es dif´ıcil estimar la duraci´on de la misma. Usar un entorno en tiempo real bajo Linux Ofrece las ventajas de un planificador en tiempo real junto a la posibilidad de uso de un sistema operativo libre, que asegure una mayor configurabilidad del mismo y un mayor aprendizaje de los aspectos internos del mismo. 27
  37. 37. 28 3.2. Modelado Est´atico Uso de herramientas libres La idea es aprovechar y contribuir en el tra- bajo de una comunidad incalculable de desarrolladores de software que nos brindan la oportunidad de utilizar, mejorar y modificar excelentes productos integr´andolos as´ı en nuestro sistema. Por ello es fundamen- tal la publicaci´on de las modificaciones que realicemos para que puedan ser aprovechadas por el resto de la sociedad ya que esta filosof´ıa es sin duda un paso adelante y una gran contribuci´on al avance tecnol´ogico. Interfaz gr´afica sencilla para la realizaci´on de las mediciones Implica el dise˜no de una interfaz gr´afica simple, completa e intuitiva que permita al usuario poco experimentado aprovechar las funcionali- dades de la aplicaci´on, de manera que pueda utilizare para multitud de ´ambitos de aplicaci´on. Adaptaci´on a Multiprocesador Hace necesario el estudio y aplicaci´on de una soluci´on para la distribuci´on del proceso a ejecutar en modo exclusivo por el planificador en tiempo real. Obtenci´on de Informaci´on sobre la m´aquina en tiempo de ejecuci´on Existe informaci´on vital para lograr una muestra v´alida de acuerdo con las caracter´ısticas del modelo de procesador sobre el que se ejecuta la aplicaci´on. Por ello el sistema debe ser capaz de obtener datos tan importantes como el n´umero de procesadores y los contadores hardware con los que cuenta la m´aquina. Entorno propio sin necesidad de configuraci´on Como consecuencia del punto anterior se debe de contar con un entorno configurado ade- cuadamente para realizar las mediciones sin que el usuario realice ins- talaciones extra y que detecte los elementos y configure el equipo de acuerdo con sus caracter´ısticas. 3.2. Modelado Est´atico Mediante el modelado est´atico se pretende establecer de un modo for- mal el comportamiento del sistema a trav´es de uso del Lenguaje Unificado de Modelado (UML). Para ello examinaremos tanto los casos de uso de la aplicaci´on, a trav´es de sus diagramas de casos de uso, como las clases invo- lucradas y sus relaciones, a trav´es su diagrama de clases. La visi´on que realizaremos se basar´a exclusivamente en la interfaz gl- perfex (describiremos la relaci´on de esta interfaz con lperfex en el modelado din´amico), ya que las especificaciones y requisitos del resto del sistema ser´an descritos en el apartado 3.6.
  38. 38. An´alisis del Sistema 29 3.2.1. Casos de Uso 3.2.1.1. Identificaci´on de los Actores El ´unico actor implicado es el usuario final. Esto se debe al cumplimiento de la premisa de funcionamiento aut´onomo del sistema, de manera que no exista la necesidad de implicar a ning´un administrador que realice configu- raciones o mantenimiento del mismo. Podemos catalogar a los usuarios entre los siguientes tipos: Investigadores y Desarrolladores Utilizan la aplicaci´on para realizar benchmarkings midiendo as´ı la optimizaci´on de un algoritmo (obser- vando las mejoras a realizar o los ´exitos de las mismas) evaluando para ello todos los eventos que la arquitectura permite medir. Docentes y Alumnos Pueden necesitar la aplicaci´on para la demostra- ci´on y validaci´on de teor´ıas a trav´es de una serie de pruebas de las mismas. Tambi´en puede utilizarse la aplicaci´on para la comprensi´on del funcionamiento interno de un procesador (en este caso deber´a li- mitarse a procesadores de las arquitecturas x86 y x86 64). 3.2.1.2. Diagrama de Casos de Uso En la Figura 3.1 podemos observar los casos de uso de nuestro sistema. Figura 3.1: Diagrama de Casos de Uso
  39. 39. 30 3.2. Modelado Est´atico 3.2.1.3. Especificaci´on de los Casos de Uso A continuaci´on especificaremos de modo formal cada uno de los casos que se han identificado a la hora de realizar el diagrama. Dado que UML no propone ning´un modelo de plantilla para definir los casos de uso, establece- remos una plantilla b´asica para especificar cada caso en el proceso. UC#id: Nombre del Caso de Uso Descripci´on breve del caso de los ob- jetivos del caso de uso. 1. Actores: Actores que intervienen en el caso de uso. 2. Precondiciones: Conjunto de condiciones que deben cumplirse para que el caso de uso se realice de forma correcta. 3. Flujo Principal: Secuencia de pasos necesarios que se deben seguir para la correcta realizaci´on del caso de uso. 4. Postcondiciones: Conjunto de condiciones que se cumplen cuando se ejecutan los pasos del flujo principal. 5. Flujo alternativo: Opciones del flujo alternativo en caso de no ejecutarse el flujo principal. Cuadro 3.1: Plantilla para la Definici´on de Casos de Uso Una vez definida la plantilla a emplear para el detallado de los casos de uso podemos realizar el proceso con los casos identificados. UC1: Generar Medici´on El usuario desea realizar una medici´on sobre una serie de contadores hardware de un programa ejecutable. 1. Actores: Usuario 2. Precondiciones: No existen precondiciones porque contamos con un sistema aut´onomo que ha detectado los elementos de la m´aquina y que contiene todo lo necesario para realizar la medi- ci´on. 3. Flujo Principal: Para realizar la medici´on de forma correcta el usuario deber´a actuar de acuerdo con los pasos que se siguen en el caso de uso UC5 (Punto de Inclusi´on). 4. Postcondiciones: Se generan una serie de estad´ısticas que refle- jan los valores de medici´on que se pidieron en la configuraci´on de la misma. 5. Flujo alternativo: Existen dos flujos alternativos que pueden operar con los datos obtenidos a partir de la medici´on generada.
  40. 40. An´alisis del Sistema 31 Se podr´an guardar los resultados de la medici´on (Punto de Extensi´on: Guardar Resultados). En este caso el usuario sim- plemente tendr´a que dar la ruta donde desea almacenar el fichero y se generar´a el mismo. Se podr´a guardar la gr´afica de la medici´on en caso de ha- ber sido generada (Punto de Extensi´on: Guardar Gr´afica). El usuario indicar´a la ruta y el tipo de imagen (formato a elegir entre una serie de formatos soportados) que desee ge- nerar para su posterior visualizaci´on. UC2: Cargar Medici´on El usuario dispone de datos extra´ıdos de medi- ciones anteriores y desea cargarlos en la aplicaci´on para examinarlos. 1. Actores: Usuario 2. Precondiciones: Existe la precondici´on de disponer de unos re- sultados guardados en el formato apropiado. 3. Flujo Principal: El usuario selecciona el fichero de resultados deseados. 4. Postcondiciones: Se publican las estad´ısticas que reflejan los valores de medici´on guardados en el fichero. 5. Flujo alternativo: - UC3: Configurar Medici´on El usuario necesita configurar la medici´on a realizar para poder generar los resultados deseados, por lo tanto se trata de un caso de inclusi´on. 1. Actores: Usuario 2. Precondiciones: - 3. Flujo Principal: El usuario debe seleccionar medici´on normal dentro de las opciones de configuraci´on. Tambi´en establecer´a el n´umero de ejecuciones que se realizar´an en las pruebas, el bina- rio a ejecutar (programa que se desea probar en el sistema) y seleccionar´a los eventos hardware que desea medir. 4. Postcondiciones: Una vez realizada la configuraci´on, se puede obtener la medici´on y enviar la consulta (haciendo una analog´ıa a las bases de datos) a lperfex para que realice la medici´on. 5. Flujo alternativo: El sistema permite realizar otro tipo de me- dici´on aparte de la est´andar y es la medici´on exclusiva (Punto de Extensi´on: Medici´on Exclusiva) que se describe en el UC4. UC4: Medici´on Exclusiva El usuario puede desear una medici´on distinta de la est´andar o normal, de acuerdo con el requisito de inclusi´on de un planificador en tiempo real.
  41. 41. 32 3.2. Modelado Est´atico 1. Actores: Usuario 2. Precondiciones: - 3. Flujo Principal: El usuario debe seleccionar medici´on exclusi- va dentro de las opciones de configuraci´on. Como caracter´ıstica fundamental de la medici´on exclusiva es que permite seleccionar el procesador o procesadores donde se desea lanzar la aplicaci´on a probar. M´as all´a de eso se realizar´an la configuraci´on de ele- mentos comunes, n´umero de ejecuciones que se realizar´an en las pruebas... 4. Postcondiciones: Igual que las establecidas en el caso base de configuraci´on de la medici´on, lperfex se encargar´a de realizar la medici´on exclusiva. 5. Flujo alternativo: - 3.2.2. An´alisis de Clases del Sistema En esta etapa del modelado est´atico se determinar´an las clases que apa- recer´an en el sistema. Se trata de una descripci´on breve sin llegar a un grado de explicaci´on que se obtendr´a en etapas siguientes del desarrollo del proyecto. 3.2.2.1. Diagrama de Clases En la Figura 3.2 podemos observar el diagrama de clases de glperfex, donde identificamos las siete clases distintas que lo componen. Figura 3.2: Diagrama de Clases
  42. 42. An´alisis del Sistema 33 3.2.2.2. Descripci´on de las Clases A continuaci´on describimos la clases indicadas en el diagrama: MainFrame Es la clase encargada de mostrar la ventana principal de glper- fex. Dentro de ella se encuentra el notebook que albergar´a los paneles que se describir´an a continuaci´on y se dirigen las operaciones de ge- neraci´on de mediciones, adem´as de dar la opci´on de almacenar dichos resultados, su gr´afica, en caso de haberse generado, y cargar resultados de mediciones anteriores. Tambi´en albergar´a las acciones para abrir la ayuda. Configuration Esta clase alberga el panel encargado de la configuraci´on de la ejecuci´on del programa. Est´a situada por encima de la clase de entrada y salida, y requiere de ella para tener acceso y contacto con el programa lperfex. Dentro de ella se realiza la configuraci´on del n´umero de ejecuciones, n´umero de procesadores a elegir, y se elige entre el caso base de prueba (medici´on est´andar) o el caso de medici´on exclusiva. Counters Clase correspondiente al panel encargado de la configuraci´on de los contadores elegidos para la medici´on, utiliza la clase de entrada y salida, situ´andose por encima de ´esta en nivel de abstracci´on de forma que obtiene los contadores propios del sistema que proporciona lperfex. Gestionar´a como como vemos a continuaci´on la clase CheckListCtrl para mostrar y operar con los contadores. CheckListCtrl Clase correspondiente simplemente al panel donde se es- cribir´an y seleccionar´an los contadores hardware de la m´aquina bajo el mando de la clase Counters. Results De la misma manera que las dos clases anteriores, esta clase corres- ponde a un panel, en este caso al encargado de mostrar los resultados de las estad´ısticas as´ı como la gr´afica de los mismos (siempre se mos- trar´a en caso de existir m´as de dos resultados de una prueba, una gr´afica con un ´unico punto no tendr´ıa sentido), para mostrar los resul- tados se har´a uso de la clase ResultsPanel. Para recoger los resultados tras la ejecuci´on se comportar´a en interacci´on de manera an´aloga a las clases anteriores con la clase IOInterface. ResultsPanel Es una clase utilizada por Results simplemente como panel de muestra de resultados. IOInterface Clase encargada de interaccionar con el programa lperfex, la idea inicial es que se comporte como una capa a parte, de manera que sea cual sea la forma elegida de interaccionar con lperfex, el resto de
  43. 43. 34 3.3. Modelado Din´amico comunicaci´on con las clases no se vea modificada. Al ser una capa de abstracci´on menor, y por propia usabilidad, las clases Configuration, Counters y Results heredar´an de ella. 3.3. Modelado Din´amico En esta fase de la especificaci´on se proceder´a a describir c´omo interact´uan entre s´ı los objetos presentes en la aplicaci´on, modificando el estado de este a lo largo del tiempo. Para ello, siguiendo el modelo de UML, se emplear´an diagramas de secuencia. Esto nos servir´a para realizar la fase de dise˜no de datos. 3.3.1. Diagramas de Secuencia Los diagramas de secuencia describen la colaboraci´on entre los objetos que componen el sistema. Se tratan de una serie de diagramas de interacci´on que detallan las operaciones que se llevan a cabo, qu´e mensajes son enviados y cu´ando. El tiempo comienza en el eje y del sistema de coordenadas car- tesiano, de forma que los eventos que ocurran en las partes inferiores ser´an los que hayan ocurrido con mayor tiempo transcurrido. De forma an´aloga objetos se situar´an conforme a su orden de participaci´on en el eje x. Estableceremos un diagrama de secuencia para los casos fundamentales de uso. Sin embargo, y por la simpleza y m´ınima variaci´on que suponen, tal y como describiremos posteriormente, resumiremos los casos de uso en dos ´unicos diagramas de secuencia. 3.3.1.1. Generar Medici´on El caso de uso Generar Medici´on (UC1), Figura 3.1, es el principal de nuestra aplicaci´on. El usuario pide al programa (aplicando una serie de confi- guraciones) que muestre por pantalla los resultados deseados. Exist´ıan tam- bi´en dos posibilidades a˜nadidas a este caso, la posibilidad de guardar los resultados de la ejecuci´on en un fichero, y la posibilidad de guardar una gr´afica con los resultados en caso de que esta hubiera sido generada (en caso de haber existido m´as de una ejecuci´on, para visualizar gr´aficamente c´omo ´esta se ajustaba a la media). La Figura 3.3 presenta el diagrama de secuencia del caso de uso Generar Medici´on, a˜nadiendo al final del mismo la operaci´on Guardar Resultados como muestra completa de las posibilidades que el programa si atacamos su
  44. 44. An´alisis del Sistema 35 funcionalidad por este sentido. Podr´ıamos haber a˜nadido tambi´en al final (a la altura de Guardar Resultados, la posibilidad de Guardar la gr´afica) sin embargo se trata de un proceso an´alogo y no se considera necesario redundar en la explicaci´on. Figura 3.3: Diagrama de Secuencia: Generar Medici´on A continuaci´on realizaremos una descripci´on paso a paso del diagrama: 1. El usuario, que tiene a su disposici´on la interfaz gr´afica (GUI) glperfex abierta se encuentra con la opci´on de configurar la ejecuci´on. Este caso de uso ten´ıa, como vimos en la secci´on 3.2.1.3, un caso especial
  45. 45. 36 3.3. Modelado Din´amico de ejecuci´on exclusiva, hemos determinado no obstante que tendr´an que aparecer todas las opciones en el mismo espacio en la ventana, adelant´andonos de este modo un poco a la especificaci´on de la interfaz, por lo que no ser´a necesaria la descripci´on, o especificaci´on de una comunicaci´on extra para las comunicaciones del usuario a la GUI. 2. El usuario necesita ahora elegir los contadores para completar la con- figuraci´on de la ejecuci´on, por ello pide a la interfaz que muestre los contadores disponibles por el sistema. En este caso podr´ıamos haber especificado el proceso que realiza la GUI a trav´es de la Interfaz de I/O para obtener esos datos de lperfex, sin embargo este proceso se realiza al iniciar la ejecuci´on de glperfex y no con la intervenci´on del usuario, por lo que se situar´ıa al principio. No obstante, se trata proce- so an´alogo al de obtenci´on de resultados, y, por supuesto, ser´a tomado en cuenta a la hora de codificar. 3. Una vez la interfaz detecta la petici´on de muestra del panel de conta- dores, la GUI muestra al usuario los contadores obtenidos (generado tal y como se coment´o en el punto 2). 4. El usuario realiza la selecci´on deseada entre los contadores que le mues- tra la GUI. 5. Una vez se han reunido los datos necesarios para generar una medici´on, el usuario puede pedir a la aplicaci´on que se genere la medici´on de su programa. 6. La GUI recopila internamente los datos que el usuario ha dado como entrada. 7. La GUI env´ıa la informaci´on recopilada para la ejecuci´on y medici´on a la Interfaz de Entrada/Salida. 8. La Interfaz de Entrada/Salida se encarga de reunir la informaci´on en una consulta v´alida para lperfex, siguiendo las especificaciones de la misma. 9. La Interfaz de I/O ejecuta lperfex con las caracter´ısticas requeridas. 10. lperfex realiza las mediciones correspondientes. 11. Una vez realizadas las mediciones, lperfex da sus resultados y la Inter- faz de I/O los recoge. 12. La Interfaz de I/O da formato a los resultados obtenidos de la ejecuci´on de lperfex. 13. Una vez reunidos los datos de la ejecuci´on y guardados en las estruc- turas requeridas por la GUI para manejarlos se mandan a la misma.
  46. 46. An´alisis del Sistema 37 14. La GUI rellena los paneles de resultados (y la gr´afica en caso de ser necesario hacerlo) de acuerdo con los datos recibidos en las estructuras correctas. 15. El usuario puede disfrutar ahora de los resultados de la ejecuci´on or- denada. En este caso el usuario podr´ıa contentarse con la ejecuci´on dada, pero existe una posibilidad m´as detallada en el diagrama que podr´ıa realizar (en realidad tal y como comentamos en la introducci´on a la descripci´on son dos an´alogas), la opci´on de guardar los resultados, puntos 16, 17, 18, 19, 20 y 21. 16. El usuario pide a la GUI guardar los resultados. 17. La GUI necesita el nombre del fichero donde se desea guardar y su ruta para transmitirlo, por ello lo solicita al usuario. 18. El usuario especifica a la GUI el nombre del fichero a ejecutar. 19. La GUI ejecuta la opci´on de guardar resultados de la Interfaz de I/O, que comunicar´a con el sistema para realizar la operaci´on. 20. La Interfaz de I/O env´ıa la confirmaci´on de escritura del fichero. 21. La GUI notifica al usuario la confirmaci´on de escritura. 3.3.1.2. Cargar Medici´on El caso de uso Cargar Medici´on nos da la oportunidad de mostrar los resultados almacenados tras alguna medici´on por pantalla. De esta manera en la Figura 3.4 se muestra el diagrama de secuencia correspondiente al caso de uso. A continuaci´on realizaremos una descripci´on paso a paso del diagrama: 1. El usuario selecciona la opci´on de cargar medici´on en la interfaz gr´afica (GUI). 2. La GUI pide al usuario el nombre y la ruta del fichero que desea cargar. 3. El usuario escribe el nombre del fichero y la ruta en la GUI. 4. La GUI da la instrucci´on a la Interfaz de Entrada/Salida para abrir el fichero deseado.
  47. 47. 38 3.4. Descripci´on de la Informaci´on Figura 3.4: Diagrama de Secuencia: Cargar Medici´on 5. La Interfaz de I/O obtiene el fichero a trav´es de una llamada al sistema y una vez abierto, almacena los datos en las estructuras requeridas por la GUI para el manejo de los datos. 6. La Interfaz de I/O env´ıa los datos formateados a GUI. 7. La GUI rellena con los datos correspondientes los paneles de resulta- dos. 8. La GUI muestra los resultados una vez rellenos los paneles (con gr´afica en caso de haberse generado). 3.4. Descripci´on de la Informaci´on Antes de realizar un enfoque a la especificaci´on de la interfaz y a la des- cripci´on del resto de componentes del sistema es importante tener en cuenta la informaci´on manipulada por la aplicaci´on. En concreto nos centraremos en la descripci´on de la informaci´on almacenada y manipulada en los casos de uso Cargar Medici´on y en el caso especial al generar medici´on, Guardar Resultados. Una de las necesidades que ya hemos comentado en los objetivos y en la especificaci´on de requisitos de nuestro sistema es la de guardar los datos
  48. 48. An´alisis del Sistema 39 de las mediciones. Si estamos inmersos en un proceso de evaluaci´on del funcionamiento de una aplicaci´on, ser´a capital comparar los resultados de las diferentes mediciones que vayamos obteniendo. La manera m´as ´util de almacenar estos resultados ser´ıa hacerlo en un for- mato entendible por programas de oficina como hojas de c´alculo, de forma que no s´olo pudieran ser visualizados en nuestro sistema, sino que pudie- ran ser manipulados externamente y tratados con una gran facilidad. Otra posibilidad ser´ıa almacenar los resultados en una base de datos. Sin embar- go, incurrir´ıamos en el supuesto que acabamos de negar, los resultados s´olo ser´ıan accesibles a trav´es de nuestro programa o mediante consultas SQL, lo que dificultar´ıa en gran manera el acceso y manipulaci´on posterior de los mismos. Con estas premisas, y tras una breve investigaci´on se ha escogido la opci´on de guardar las estad´ısticas en un formato especial llamado comma- separated values (CSV). 3.4.1. El Formato CSV Los ficheros CSV son un tipo de documento sencillo para representar datos en forma de tabla. En ellas las columnas se separan por comas (o punto y coma, dependiendo del estilo que escogido para la separaci´on decimal) y las filas por saltos de l´ınea. Los campos que contengan una coma, un salto de l´ınea o una comilla doble deben ser encerrados entre comillas dobles. El formato CSV es muy sencillo y no indica un juego de caracteres con- creto, ni c´omo van situados los bytes, ni el formato para el salto de l´ınea. Estos puntos deben indicarse muchas veces al abrir el fichero, por ejemplo, con una hoja de c´alculo [22]. La principal ventaja de CSV, adem´as de la especificaci´on sencilla1 y so- portada por multitud de lenguajes de programaci´on, es que las principales herramientas de hojas de c´alculo del mercado son capaces de leer y operar con dicho formato (OpenOffice.org Calc y Excel de Microsoft Office entre ellas). De esta manera el usuario de nuestra aplicaci´on podr´a tratar los resul- tados en hojas de c´alculo facilitando la labor de documentaci´on y evaluaci´on de las pruebas. 1 Probablemente no exista ninguna especificaci´on m´as sencilla que la de CSV. No obs- tante, hay que matizar que no existe una especificaci´on formal para los ficheros CSV. Las ´unicas directrices fueron dadas en el documento RFC 4180 [23] que describe un formato com´un y establece el tipo MIME “text/csv”, registrado por la Internet Assigned Numbers Authority (IANA). Otra especificaci´on importante es la provista por el est´andar Fielded Text [24] que cubre en un apartado el formato CSV. Se pueden encontrar m´as referencias a la especificaci´on en [25] y [26].
  49. 49. 40 3.4. Descripci´on de la Informaci´on Contador,Resultado,Tiempo,Tiempo Sys NOMBRECONTADOR0,RESULTADO,TIEMPO,TIEMPOSYS NOMBRECONTADOR1,RESULTADO,TIEMPO,TIEMPOSYS NOMBRECONTADOR2,RESULTADO,TIEMPO,TIEMPOSYS NOMBRECONTADOR3,RESULTADO,TIEMPO,TIEMPOSYS ..... Cuadro 3.2: Ejemplo de Fichero CSV resultado de una medici´on Contador,Resultado medio,Desviaci´on,Tiempo,Tiempo Sys,N. Ejecuciones NOMBRECONTADOR0,RESULTADOMEDIO,DESVIACI´ON,T,T_SYS,3 N. Ejecuci´on,Resultado 1, Valor1 2, Valor2 3, Valor3 NOMBRECONTADOR1,RESULTADOMEDIO,DESVIACI´ON,T,T_SYS,3 N. Ejecuci´on,Resultado 1, Valor1 2, Valor2 3, Valor3 .... Cuadro 3.3: Ejemplo de Fichero CSV resultado de tres mediciones 3.4.2. Nuestro Uso de CSV Tal y como hemos visto en la descripci´on de CSV el formato almacena los datos en columnas separadas por comas y filas establecidas como saltos de l´ınea. De esta manera, el objetivo es escribir en el fichero la informaci´on tabulada que aparecer´a en los paneles de resultados que coment´abamos en los diagramas de secuencia. Establecemos dos modelos de registro de datos, la clasificaci´on viene dada por el n´umero de ejecuciones que ha ordenado el usuario de cada contador. El Cuadro 3.2 muestra el modelo fichero en caso de prueba de una ´unica medici´on de varios contadores, mientras que el Cuadro 3.3 muestra el fichero en caso de tres ejecuciones de varios contadores. La presentaci´on de estos dos ficheros CSV en OpenOffice.org Calc resul- tar´a tal y como podemos observar en las Figuras 3.5 y 3.6 f´acil de tratar por
  50. 50. An´alisis del Sistema 41 el usuario final y asegurar´a que el Caso de Uso de almacenaje de los datos sea totalmente funcional una vez escrito el fichero. Figura 3.5: Ejemplo de Fichero CSV: Una medici´on 3.5. Requisitos de la Interfaz Una vez conocidas las restricciones propuestas a la interfaz, as´ı como los casos de uso principales, es hora de dar la primera aproximaci´on a las normas que deber´a obtener la interfaz final. Nuestro sistema de medici´on tiene dos interfaces fundamentales, La interfaz proporcionada por Karma Linux original, es decir, uso de lperfex mediante la interacci´on con a trav´es del est´andar getopts con la terminal y el programa documentada en [1]. La interfaz de Karma Linux 2008, glperfex, en modo gr´afico con el objetivo de cumplir su funci´on de manera sencilla y ´agil para el usuario. En este apartado describiremos la segunda interfaz al tratarse de la pro- pia de nuestro proyecto, y de una de los objetivos fundamentales de Karma Linux 2008. Las normas o requisitos de glperfex son los siguientes:
  51. 51. 42 3.5. Requisitos de la Interfaz Figura 3.6: Ejemplo de Fichero CSV: Tres mediciones La interfaz debe permitir la configuraci´on de la clase de ejecuci´on (est´andar o exclusiva), un n´umero de ejecuciones dado por el usuario, as´ı como el n´umero de procesadores donde se ejecutar´a la aplicaci´on en caso de producirse una medici´on exclusiva. Debe permitir la carga de uno o m´as eventos de procesador para su medici´on, por lo que estos eventos deber´an estar disponibles con una descripci´on de los mismos de manera que el usuario pueda configurarlos de forma correcta. La interfaz deber´a publicar los resultados de una forma entendible para el usuario. En caso de producirse la medici´on de un evento en m´as de una ocasi´on, se deber´a generar una gr´afica con los resultados sobre un eje cartesiano de manera que se pueda ver la variaci´on con respecto de la media de los mismos. Deber´a ofrecer la posibilidad de guardar los resultados generados en un fichero, as´ı como la gr´afica en caso de haber sido generada. Deber´a ofrecer la posibilidad de cargar resultados generados en medi- ciones anteriores en el sistema. En caso de necesitarla el usuario podr´a consultar una opci´on de ayuda donde aclarar las mismas.
  52. 52. An´alisis del Sistema 43 La interfaz deber´a emitir mensajes de error cuando falten datos por introducir y/o estos datos sean err´oneos de la forma m´as sencilla po- sible. 3.6. Descripci´on y Especificaciones del Resto del Sistema En las secciones anteriores hemos realizado el an´alisis de la aplicaci´on glperfex que con el uso conjunto de lperfex utilizaremos para realizar las mediciones y obtener los resultados de las mismas tanto de forma exclusiva como mediante el uso del planificador est´andar del kernel de Linux. Una vez definidas las especificaciones de la aplicaci´on debemos extender este an´alisis al contexto en el que se encuentra la aplicaci´on, por lo que en esta secci´on nos encargaremos de analizar todos los objetos del dominio as´ı como sus requisitos funcionales y no funcionales. 3.6.1. Planificaci´on de Procesos Los sistemas operativos multitarea se dividen en dos tipos, los sistemas operativos multitarea cooperativa y los de multitarea de reemplazo [2]. Multitarea Cooperativa En estos sistemas un proceso no deja de ejecu- tarse hasta que ´el mismo as´ı lo decida, el acto de suspensi´on voluntaria de la ejecuci´on es llamado yielding o cesi´on. Debido a esto, el proce- sador no puede tomar decisiones globales sobre qu´e proceso ejecutar, los procesos pueden monopolizar el procesador durante un periodo de tiempo muy largo y se corre el riesgo de que dichos procesos no cedan jam´as uso del procesador. Uno de los escasos ejemplos de sistemas ope- rativos multitarea cooperativa es el MacOS 9 y versiones anteriores. Multitarea de Reemplazo Al contrario que en los sistemas multitarea cooperativa aqu´ı es el planificador el que decide cu´ando un proceso debe cesar su ejecuci´on y cu´ando un proceso debe continuarla. El acto de suspender una tarea en ejecuci´on es llamado preempt o reemplazo. El tiempo que un proceso ejecuta antes de su reemplazo es determina- do con anterioridad, aunque puede variar en caso de imprevistos. Este periodo de ejecuci´on antes de su reemplazo es llamado cuanto y var´ıa para cada sistema operativo y cada tarea. Unix posee multitarea de reemplazo desde el comienzo y por tanto Linux tambi´en, al igual que la mayor´ıa de sistemas operativos modernos. En Linux el cuanto de
  53. 53. 44 3.6. Descripci´on y Especificaciones del Resto del Sistema tiempo de ejecuci´on es calculado din´amicamente permitiendo al plani- ficador tomar decisiones globales sobre el sistema. Esta naturaleza de reemplazo y divisi´on en cuantos, previene que un proceso monopolice la CPU. Como hemos podido ver, en Linux, una tarea no obtiene el control ab- soluto de la CPU de ninguna forma. En la rama 2.6 del kernel se han des- activado las llamadas sti() y cli(), restringiendo el acceso a la activaci´on y desactivaci´on de interrupciones, lo que obliga al programador a usar otras t´ecnicas para la sincronizaci´on de drivers. Esta restricci´on, que deja todo el control de los procesos al sistema operativo, tiene el objetivo de asegurar un sistema fiable con una mayor transparencia y mejor interacci´on con el usuario final. Un ejemplo de ello podemos encontrarlo en la forma de tratar los cuan- tos de tiempo en el planificador del kernel de Linux. Tal y como podemos observar en la Figura 3.7, el planificador asigna un cuanto de tiempo que var´ıa desde los 10 milisegundos hasta los 200 dependiendo de la prioridad de la tarea y de la interactividad que requiera, es decir, a mayor interactivi- dad, mayor ser´a el cuanto de tiempo, ya que es preferible que el usuario no permanezca a la espera eternamente. Figura 3.7: Cuantos de tiempo en el planificador de Linux Estas decisiones tomadas para mejorar la capacidad de interacci´on del sistema operativo son a su vez el principal problema a la hora de realizar las mediciones. Nuestra tarea es reemplazada por otra, pero sin embargo los contadores siguen midiendo de tal forma que incluso creando una serie de contadores virtuales que midan s´olo una tarea desactiv´andose al ser reem- plazada, los contadores medir´ıan el cambio de contexto, la llamada al nuevo proceso y en cada cuanto que vuelva a ocupar nuestro proceso el procesador, los contadores medir´ıan de nuevo su cambio de contexto, y lo que es m´as importante, el proceso cometer´ıa errores forzados en la memoria cach´e, que se traducir´ıan en una cantidad variable de ciclos de procesador adicional, m´as accesos a cach´e tanto de nivel 1 como de nivel 2, etc.

×