PROYECTO SISTEMAS INFORMÁTICOS

Transcripción

1 PROYECTO SISTEMAS INFORMÁTICOS CURSO INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA GUILLERMO MARTÍNEZ FERNÁNDEZ SERGIO SÁNCHEZ GORDO SOFÍA DRONDA MERINO DIRIGIDO POR: PROF. CARLOS GARCÍA SÁNCHEZ PROF. JUAN CARLOS SÁEZ ALCAIDE FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID

2

3 RESUMEN La finalidad del proyecto Interfaz de uso de Contadores Hardware multiplataforma consiste en crear una herramienta multiplataforma que consiga monitorizar el rendimiento de un programa haciendo uso de los contadores hardware integrados en el procesador. La portabilidad a otras arquitecturas así como a otros sistemas operativos o versiones de kernel será lo que marque la diferencia con el resto de herramientas del mismo propósito. Se ha diseñado una herramienta modular para facilitar dicha portabilidad a otras arquitecturas con distintos contadores hardware. Además, las dependencias en el sistema operativo han sido eliminadas, buscando la abstracción en módulos que son cargados según la plataforma objetivo. ABSTRACT The aim of this project consists on develop a multi- platform tool that allows performance monitoring by means of the use of hardware counters available in modern processors. The portability to other architectures, as well as other operative systems and kernel versions, is the main difference behind other similar solutions. A modular tool has been designed to facilitate its portability to other systems with different hardware counters set. Moreover, the operative system dependencies have been is isolated by kernel modules using which avoid any target platform dependencies.

4

5 LISTA DE PALABRAS C contadores hardware, 3, 1, 2, 4, 6, 7, 8, 20, 28, 34, 51, 52 cputrack, 2, 3, 4, 6, 40, 41, 51, 52 K kernel, 3, 11, 1, 4, 5, 7, 8, 14, 15, 16, 17, 18, 19, 20, 22, 24, 34, 51, 73 liberación de recursos, 18 L M módulo, 15, 18, 19, 20, 22, 24, 25, 26, 28, 30, 31, 37, 38 monitorización, 11, 2, 4, 16, 18, 19, 20, 25, 26, 27, 28, 31, 34, 36, 37, 40, 51, 56, 57, 58, 59, 62, 64, 67, 71 operaciones atómicas, 23, 33 O P pcm- power, 2, 3 planificador, 2, 5, 9, 12, 14, 51, 54, 55 pmctrack, 4, 6, 34, 35, 36, 37, 38, 40, 41, 50, 51 proceso, 11, 2, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 20, 21, 22, 23, 26, 27, 28, 31, 32, 33, 34, 35, 36, 37, 54, 71 sincronización, 8, 23, 33 S

6

7 AGRADECIMIENTOS Queremos dar nuestro más sincero agradecimiento a nuestros directores de proyecto, Carlos García y Juan Carlos Sáez, por invertir tanto tiempo en nosotros y por su paciencia. También nos gustaría dar las gracias a nuestros familiares por el apoyo recibido, no sólo en estos años universitarios, sino durante toda nuestra vida. Y por último y no menos importante, a nuestros amigos. Por esos momentos de distracción y sus ánimos incondicionales. Sin ninguno de ellos esto no hubiera sido posible. A todos ellos, muchas gracias.

8

9 ÍNDICE INTRODUCCIÓN CONTADORES HW DE RENDIMIENTO HERRAMIENTAS DE MONITORIZACIÓN MOTIVACIÓN RESUMEN DEL CONTENIDO... 5 MODIFICACIÓN DEL KERNEL GNU- LINUX ESTRUCTURA DEL KERNEL PROCESOS Creación de procesos: Fork y Clone Finalización de procesos: Exit Esperar por un proceso: Wait PLANIFICADOR DE TAREAS MODIFICACIONES MÓDULOS INSTALACIÓN Y DESINSTALACIÓN IMPLEMENTACIÓN SISTEMA DE FICHEROS PROCFS GESTIÓN DE FICHEROS DEL PROCFS ENTRADA MOD_ENABLE_PMCS ENTRADA MOD_PMC_CONFIG ENTRADA MOD_MONITOR_PMCS HERRAMIENTA MULTIPLATAFORMA MANEJO MODO MONITORIZACIÓN MODO CONFIGURACIÓN RESULTADOS VALIDACIÓN BENCHMARKS EXTENSIÓN DE LA HERRAMIENTA EN AMD CONCLUSIONES Y APORTACIONES APÉNDICES I. VERSIÓN DE LINUX II. CONTADORES HW DE RENDIMIENTO EN INTEL III. CONTADORES HW DE RENDIMIENTO EN AMD BIBLIOGRAFÍA... 77

10

11 Capítulo 1: Introducción CAPÍTULO 1 INTRODUCCIÓN Este proyecto de fin de carrera aborda el uso de contadores hardware para evaluar el rendimiento de una aplicación. La motivación principal es conseguir que cualquier sistema operativo, arquitectura o versión de kernel puedan hacer uso de los contadores tanto a nivel de usuario como de sistema. En este capítulo hablaremos de los contadores hardware de rendimiento. Explicaremos algunas herramientas de monitorización ya existentes. Expondremos los principales motivos que nos han llevado al desarrollo de este proyecto. Por último resumiremos el contenido de la memoria del proyecto. INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA 1

12 Capítulo 1: Introducción 1.1 CONTADORES HW DE RENDIMIENTO Los contadores fueron introducidos en los procesadores para la monitorización del rendimiento de la CPU. Son contadores específicos que ocupan un área despreciable dentro del chip. Estos contadores permiten seleccionar los parámetros de rendimiento del procesador para ser medidos y monitorizados. La información obtenida puede ser usada para ajustar el sistema y observar el rendimiento. 1.2 HERRAMIENTAS DE MONITORIZACIÓN En la actualidad, ya existen varias herramientas que realizan la tarea de monitorizar los contadores y obtener sus medidas. El gran inconveniente de las herramientas actuales es la dependencia del SO, de las arquitecturas, etc. Por otro lado, encontramos que la mayoría de las herramientas sólo permiten el funcionamiento únicamente en modo usuario, no encontrándose en la actualidad la posibilidad de interacciones a bajo nivel, como por ejemplo con el planificador del sistema operativo. Entre las herramientas disponibles en la actualidad destacamos cputrack 1, sólo disponible para el sistema Solaris; y pcm- power 2, para las arquitecturas de Intel. A continuación, analizaremos estas herramientas: CPUTRACK: Solaris 8 OE contiene una serie de APIs que están disponibles como librerías compartidas para programar los contadores hardware. Además, existen herramientas útiles como son cpustat y cputrack para acceder a estos contadores del microprocesador a través de la línea de comandos. La utilidad de cputrack es informar sobre los contadores de rendimiento de la CPU devolviendo la medición de un evento de un proceso. Los contadores suspenden la cuenta cuando se produce un cambio de contexto; y se restaura cuando el proceso es devuelto a la CPU. Para lanzar la ejecución de esta aplicación no es necesario ser administrador. Además, esta herramienta contiene gran cantidad de aspectos configurables. La elección del evento a medir, el tiempo de muestreo o el volcado a un fichero son algunos de ellos. 1 Ver su implementación en gate/usr/src/cmd/cpc/common/cputrack.c 2 Información y descarga de la herramienta en us/articles/intel- performance- counter- monitor- a- better- way- to- measure- cpu- utilization#intro 2 INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA

13 Capítulo 1: Introducción Ejemplo de salida de cputrack: # cputrack -T 0 -fve -c Cycle_cnt,Instr_cnt sh -c date time pid lwp event pic0 pic init_lwp fork # init_lwp fini_lwp exec exec # 'date' init_lwp fini_lwp exit fini_lwp exit PCM- POWER: Los procesadores Intel ya proporcionan la capacidad de monitorizar los eventos del rendimiento dentro del procesador. Para obtener con más precisión una imagen de la utilización de la CPU se confía en los datos dinámicos que se obtienen llamando a las Unidades de Monitorización del Rendimiento (PMU) implementado en los procesadores. Estas características avanzadas están disponibles en los siguientes procesadores Intel Xeon 5500, 5600, 7500, E5, E7 y Core i7. Se han puesto en marcha un conjunto de rutinas con una interfaz de alto nivel que se puede llamar desde el usuario proporcionando diversos parámetros de rendimiento de la CPU en tiempo real. Una característica interesante es su uso para core y para las unidades de gestión uncore del procesador Intel. El uncore es la parte del procesador que contiene el controlador de memoria integrado. En general, las siguientes mediciones son compatibles: Ø Core: Instrucciones retiradas, transcurridos nticks de reloj del núcleo, accesos y fallos de calle L2 y L3. Ø Uncore: Lee y escribe bytes desde el controlador de memoria y el tráfico de datos transmitidos por el procesador. Gracias a la capa de abstracción que proporciona la biblioteca, es muy fácil de supervisar las métricas del procesador dentro de su aplicación. Antes de su uso, los contadores de rendimiento deben ser inicializados. Luego, el estado del contador puede ser capturado antes y después de la sección de código de interés. Diferentes rutinas capturan los contadores de los cores, tomas de corriente o el sistema completo, y almacenan su estado en las estructuras de datos correspondientes. Otras rutinas adicionales ofrecen la posibilidad de calcular la métrica basada en estos estados. La utilidad pcm- power esta incorporada en el procesador Intel Xeon serie E5, PCM versión 2.0. INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA 3

14 Capítulo 1: Introducción El fragmento de código siguiente muestra un ejemplo de su uso: PCM * m = PCM::getInstance(); // program counters, and on a failure just exit if (m- >program()!= PCM::Success) return; SystemCounterState before_sstate = getsystemcounterstate(); [run your code here] SystemCounterState after_sstate = getsystemcounterstate(); cout << Instructions per clock: << getipc(before_sstate,after_sstate) << L3 cache hit ratio: << getl3cachehitratio(before_sstate,after_sstate) << Bytes read: << getbytesreadfrommc(before_sstate,after_sstate) << [and so on] 1.3 MOTIVACIÓN La motivación principal del proyecto es desarrollar una herramienta de monitorización de los contadores hardware de rendimiento que elimine los requisitos de arquitectura, sistema operativo o versión de kernel que limitan la portabilidad en las herramientas actuales. Esta portabilidad es posible aislando al máximo las modificaciones a realizar en el kernel del sistema operativo, trasladando la programación de los contadores hardware a módulos independientes. El diseño modular posibilita la portabilidad, siendo necesaria la definición de una interfaz que enlace el modulo con el kernel para hacer posible la manipulación de los contadores. Por ultimo, se ha creado un herramienta programada en C llamada pmctrack inspirada en cputrack. Permite tanto monitorizar a nivel de usuario el rendimiento de un programa como configurar los registros eligiendo entre una gran variedad de eventos. Algunos de estos eventos pueden ser la medición de fallos de cache, los accesos a la misma, las instrucciones por ciclo, los fallos de TLB, etc. Gracias a la modularidad de este proyecto, evitamos la dependencia del kernel del sistema operativo. Esta división es importante para facilitar el desarrollo, la depuración y el mantenimiento. La interfaz de uso es similar que la herramienta de Solaris cputrack. Por otro lado se ha validado nuestra herramienta comparando resultados de rendimiento con cputrack (ver capítulo 6.1 Validación). A día de hoy, la herramienta pmctrack puede ser utilizada en las siguientes arquitecturas: Xeon, Atom, Core 2 Duo y AMD. Sin embargo, la extensión a otras arquitecturas o a las que aparezcan en el futuro es sencillo gracias al diseño modular empleado. La figura adjunta resume gráficamente el trabajo desarrollado de este proyecto. 4 INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA

15 Capítulo 1: Introducción KERNEL MÓDULO register_module() module_init() INSMOD SISTEMA KERNEL INTERFACE FUNCTIONS MODULE FUNCTIONS IMPLEMENTATION unregister_module() module_exit() RMMOD Sys_call USUARIO APLICACIÓN Read Write 1.4 RESUMEN DEL CONTENIDO A lo largo de la memoria profundizaremos en el desarrollo del proyecto. La división de temas está estructurada de la siguiente manera: Capítulo 2: Modificaciones realizadas en el kernel de GNU- Linux para dar soporte a la interacción con los contadores hardware. Detalle de diversos aspectos sobre la creación y liberación de procesos así como la labor del planificador de tareas. Capítulo 3: Exposición del funcionamiento de los módulos del kernel. Creación, estructuración interna, instalación y desinstalación en el kernel. La mayor parte de codificación recae en esta sección por lo que se ha analizado en detalle la creación de un módulo para Intel Core 2 Duo. Capítulo 4: En este capítulo se introduce el sistema de ficheros procfs que servirán de interfaz en los contadores hardware, el módulo del kernel y la herramienta desarrollada. INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA 5

16 Capítulo 1: Introducción Capítulo 5: Funcionamiento e implementación de la herramienta desarrollada pmctrack. Capítulo 6: Comprobación de resultados entre cputrack y la herramienta desarrollada pmctrack. Validación de la herramienta pmctrack, mediante la comparación entre esta y cputrack. Resultados experimentales usando la herramienta pmctrack sobre algunos benchmarck del SPEC2006. Ejecución de pmctrack sobre un procesador AMD. Conclusiones finales del proyecto y apéndices con información relevante sobre los contadores hardware. 6 INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA

17 Capítulo 2: Modificación del Kernel GNU- Linux CAPÍTULO 2 MODIFICACIÓN DEL KERNEL GNU-LINUX La estructuración del kernel de cualquier sistema operativo es muy compleja. En este capítulo trataremos algunos conceptos importantes como las estructuras internas de los procesos y la información que portan, su creación y su liberación de memoria así como su planificación. Se explicará también la relación que existe entre procesos padres e hijos, debido a que es relevante para nuestra herramienta desarrollada. Por último, una vez entendido el funcionamiento general del kernel, se explicará la integración de ciertas funciones que permitirán la manipulación de los contadores hardware por parte del sistema. INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA 7

18 Capítulo 2: Modificación del Kernel GNU- Linux 2.1. ESTRUCTURA DEL KERNEL El kernel es un complejo software que constituye la parte más importante de cualquier sistema operativo. Es el principal responsable de facilitar a los distintos programas acceso seguro al hardware de la computadora. Además, se encarga de la gestión de recursos a través de servicios de llamada al sistema. En el caso de Unix el lenguaje utilizado casi en su totalidad es C, a excepción del manejador de interrupciones que está escrito en lenguaje ensamblador. Opera como asignador de recursos para cualquier proceso que necesite hacer uso de las facilidades de cómputo. Entre las tareas que realiza podemos destacar: Ø Creación de procesos, asignación de tiempos de atención y sincronización. Ø Asignación del procesador a los procesos que lo requieren. Ø Administración de espacio en el sistema de archivos, que incluye: acceso, protección y administración de usuarios; comunicación entre usuarios y entre procesos, y manipulación de E/S y administración de periféricos. Ø Supervisión de la transmisión de datos entre la memoria principal y los dispositivos periféricos. Consta de dos partes principales: la sección de control de procesos y la de control de dispositivos. La primera asigna recursos, programas, procesos y atiende sus requerimientos de servicio; la segunda, supervisa la transferencia de datos entre la memoria principal y los dispositivos del ordenador. Introducir modificaciones en el kernel requiere una comprensión detallada de algunos conceptos como la información asociada a un proceso y su almacenamiento, el orden de atención de los mismos y su creación o liberación de los recursos del sistema. Este capítulo ahonda en estos conceptos con el objetivo de aclarar las modificaciones que han de introducirse para soportar la interacción con los contadores hardware. 2.2 PROCESOS Antes de comenzar, sería conveniente remarcar la diferencia entre dos conceptos parecidos pero no iguales: programa y proceso. Un programa es una colección de instrucciones que el procesador interpreta y ejecuta. Los programas se almacenan de modo permanente en memoria secundaria. Posteriormente, se mueven a memoria principal para poder ser ejecutados. Por otro lado, un proceso es un programa en ejecución. Como consecuencia de ello, el sistema operativo le asigna recursos como memoria, dispositivos, archivos, CPU, etc. En Linux, cada proceso del sistema tiene descriptor asociado que lo identifica como único. Este descriptor es un estructura llamada task_struct que almacena toda la información relacionada con el proceso como aspectos de planificación, 8 INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA

19 Capítulo 2: Modificación del Kernel GNU- Linux identificadores, relación con otros procesos, memoria utilizada por el proceso o los archivos abiertos por el mismo. Para este proyecto es importante conocer los posibles estados en los que se puede encontrar un proceso a lo largo de su vida. El campo de la estructura task_struct que se encarga de portar esta información es exit_state. En él se describe la situación en que se encuentra el proceso al haber dejado de ejecutarse en la CPU. Ø TASK_RUNNING: El proceso es ejecutable y por tanto se encuentra en la Cola de Prioridad, ya sea en ejecución, o esperando su turno. El valor por defecto de esta constante es 0. Ø TASK_INTERRUPTIBLE: El proceso está suspendido esperando a que se cumpla alguna condición. Cuando esto ocurra, el proceso será despertado y puesto en estado TASK_RUNNING. Sin embargo, también puede ser despertado de forma prematura si recibe alguna señal (por ejemplo, SIGTERM). Los procesos interactivos suelen estar suspendidos en este estado. Ø TASK_UNINTERRUPTIBLE: Igual que el caso anterior, salvo que el proceso no será despertado si recibe alguna señal. Ø TASK_TRACED: El proceso está siendo depurado. Ø TASK_STOPPED: La ejecución del proceso ha sido detenida. En este caso el proceso ya no se ejecuta ni puede ser elegido por el planificador para ejecución. Esto ocurre cuando la tarea recibe las señales SIGSTOP, SIGSTP, SIGTTIN o SIGOUT, o bien, si se recibe cualquier señal mientras está siendo depurada. Ø EXIT_ZOMBIE: El proceso ha acabado, pero su descriptor sigue en memoria por si el padre necesita alguna información. Dicho descriptor será eliminado cuando el padre ejecute la llamada al sistema sys_wait. Ø EXIT_DEAD: El proceso ha acabado y se ha eliminado su descriptor. El mecanismo más empleado para cambiar el estado de un proceso es utilizando las macros set_task_state(task, state) y set_current_state(state). La diferencia es que la segunda sólo cambia el estado del proceso current, que es aquel que se encuentra actualmente en ejecución. Las transiciones entre estados de los procesos quedan reflejadas en la figura 2.1. Pueden observarse funciones como fork(), do_exit(), schedule() o context_switch() que se llaman en la creación, liberación, planificación y cambio de contexto de un proceso respectivamente. Se hablará de cada una de ellas más adelante. INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA 9

20 Capítulo 2: Modificación del Kernel GNU- Linux Figura 2.1: Estados de los procesos CREACIÓN DE PROCESOS: FORK Y CLONE Los procesos en Linux tienen una estructura jerárquica, es decir, un proceso padre puede crear un nuevo proceso hijo y así sucesivamente. La forma en que un proceso crea a otro es mediante una llamada al sistema: fork o clone. Ambas llamadas al sistema tienen la misma funcionalidad, pero distintas características: fork: En el momento de la llamada a fork el proceso hijo: Es una copia exacta del padre excepto el PID. Tiene las mismas variables y ficheros abiertos. Las variables son independientes (padre e hijo tienen distintas memorias). Los ficheros son compartidos (heredan el descriptor). clone: Permite especificar qué queremos que compartan padre e hijo. Espacio de direccionamiento. Información de control del sistema de archivos (file system). Descriptores de archivos abiertos. 10 INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA

21 Capítulo 2: Modificación del Kernel GNU- Linux Gestores de señales o PID. En resumen, cuando se hace un fork, se crea un nuevo descriptor de proceso a partir del task_struct del proceso padre. Al hijo se le asigna un PID propio y se le copian las variables del proceso padre. Sin embargo, en la llamada al sistema clone el task_struct del proceso padre se copia y se deja tal cual, por lo que el hijo tendrá el mismo PID y obtendrá (físicamente) las mismas variables que el proceso padre. El proceso hijo creado es una copia del padre (mismas instrucciones, misma memoria). Lo normal es que a continuación el hijo ejecute una llamada al sistema exec. En cuanto al valor devuelto por fork, depende de varias opciones: Ø Si se produce algún error en la ejecución, el valor devuelto es - 1. Ø Si no se produce ningún error y nos encontramos en el proceso hijo, se devuelve el valor 0. Ø Si no se produce ningún error y nos encontramos en el proceso padre, el valor devuelto es el PID asignado al proceso hijo. Ambas llamadas al sistema terminan ejecutando do_fork() que es la función principal del archivo fork.c. A continuación, se explicará a grandes rasgos su funcionamiento: Ø Invocar a copy_process para crear un proceso, generando un nuevo task_struct y sus recursos. Una vez creado el descriptor del proceso hijo, se le asignará una CPU llamando a sched_fork. Ø Obtener el identificador del proceso hijo que se creó en la función copy_process. Ø Devolver el identificador del proceso hijo FINALIZACIÓN DE PROCESOS: EXIT La llamada al sistema exit es la primera en la sys_call_table y es la función que termina con la ejecución de un proceso. Esta función se encarga de retirar los recursos que están siendo utilizados por el proceso, así como dejarlo preparado para su posterior eliminación. Cuando un proceso termina debe de comunicar a su padre su finalización por medio de la señal SIGCHLD, de forma que una vez el padre haya sido informado y realice un wait, el hijo sea totalmente eliminado, borrándolo de la tabla de procesos. Para reflejar este hecho, se denomina al estado transitorio entre la comunicación de la finalización y la eliminación total como estado zombie. Además de notificar al padre, exit se encarga de liberar recursos como la memoria tomada por el proceso, así como el sistema de ficheros y las entradas en el mismo y los registros de estado del procesador. Si dicho proceso no tuviera padre, ya que éste hubiera concluido antes que él, se eliminaría directamente del planificador sin comunicar su estado de finalización. INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA 11

22 Capítulo 2: Modificación del Kernel GNU- Linux Interiormente, exit realiza una llamada a la función do_exit(). Ésta es la función principal del archivo exit.c y es la que realmente se encarga de la liberación de los recursos. Como se ha comentado anteriormente, do_exit() puede realizar una de las siguientes tareas según el estado del padre: Ø Si el padre existe, se invoca a la función exit_notify, la cual notifica al padre la terminación de uno de sus hijos quedándose éste en estado zombie. Ø En el caso de que el padre haya terminado sin realizar ningún wait para esperar a sus procesos hijos, se llamaría a la función release_task. Ésta es la que se encarga de liberar por completo el proceso del sistema ESPERAR POR UN PROCESO: WAIT La función wait suspende la ejecución del proceso actual hasta que un proceso hijo haya terminado, o hasta que se produzca una señal cuya acción es interrumpir el proceso actual llamando al manejador correspondiente. Cuando un proceso hijo finaliza, quedándose en estado zombie, y el padre realiza una llamada a la función wait, se captura su estado de terminación. Posteriormente, se elimina de la tabla de procesos y se informa al padre. Se puede esperar por un hijo mediante una familia de funciones que tienen como objetivo principal esperar hasta que el estado de los hijos lanzados cambie para retornar la información de dicho proceso. El cambio de estado de los hijos por los que esperar viene determinado por las opciones de la llamada al sistema. Las llamadas tiene esta sintaxis: pid_t wait(int *status) pid_t waitpid(pid_t pid, int *status, int options) int waitid(idtype_t idtype, id_t id, siginfo_t *infop, int options) La función waitpid suspende la ejecución del proceso en curso hasta que un hijo especificado por el argumento pid termine. Sus argumentos de entrada son: Ø int *status: Puntero donde debe el hijo devuelve su información el hijo. Ø pid_t pid: Un valor tal que: < - 1: Esperar por cualquier proceso cuyo Process Group ID sea igual al valor absoluto de pid. - 1: Esperar por cualquier hijo. 0: Esperar por cualquier hijo cuyo Process Group ID sea igual al del proceso llamador. > 0: Esperar por el hijo cuyo PID sea igual al valor de pid. Ø int options: Una combinación de los siguientes flags: 12 INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA

23 Capítulo 2: Modificación del Kernel GNU- Linux WEXITED: Espera por hijos que hayan terminado. WSTOPPED: Espera por hijos que hayan sido parados por recibir una señal. WNOHANG: Comprueba si el hijo ha terminado sin bloquear el proceso que está en ejecución. WNOWAIT: Dejar al hijo sin modificar ni marcar en la tabla de procesos, tal que una posterior llamada se comportaría como si no hubiésemos hecho wait por dicho hijo. WUNTRACED: No esperar si el hijo está parado, a no ser que esté siendo trazado. WCONTINUED: Volver si un hijo ha continuado ejecutándose tras mandarle la señal SIGCONT (desde la versión ). Los flags WUNTRACED y WCONTINUED solo son efectivos si SA_NOCLDSTOP no ha sido establecido para la señal SIGCHLD. Si status no es NULL, wait o waitpid almacena la información de estado en la memoria apuntada por status. Ambos devuelven el identificador del proceso hijo que ha finalizado. En caso de error devuelven - 1. Y en el caso de utilizar waitpid con la opción WNOHANG y ningún hijo esté disponible, se devuelve 0. Por otro lado, la llamada waitid es una función análoga a las otras dos con la diferencia de que ésta proporciona un mayor control sobre qué cambios de estado en el hijo deben ser esperados. En este caso, si la función tiene éxito la información del proceso hijo se devuelve en la variable infop. Devuelve 0 si tuvo éxito o si se utilizó WNOHANG y no había hijos por los que esperar. Si hubo error devuelve PLANIFICADOR DE TAREAS El planificador es un componente funcional muy importante de los sistemas operativos multitarea y multiproceso, y es esencial en los sistemas operativos de tiempo real. Su función consiste en repartir el tiempo disponible de un microprocesador entre todos los procesos que están disponibles para su ejecución. Linux usa un algoritmo razonablemente simple para planificar las prioridades y seleccionar el proceso siguiente. Cuando ha elegido un nuevo proceso para ejecutar, el planificador salva el estado del proceso en curso, los registros específicos del procesador y otros contextos en la estructura de datos task_struct. Luego restaura el estado del nuevo proceso (que también es específico a un procesador) para ejecutarlo y da control del sistema a ese proceso. Para que el planificador asigne el tiempo de la CPU justamente entre los procesos ejecutables en el sistema, el planificador mantiene INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA 13

24 Capítulo 2: Modificación del Kernel GNU- Linux cierta información en la estructura task_struct de cada proceso. La información más relevante es la siguiente: Ø policy: Esta es la política de planificación que se aplicará a este proceso. Hay dos tipos de procesos en Linux, normales y de tiempo real. Los procesos de tiempo real tienen una prioridad más alta que los otros. Si hay un proceso de tiempo real listo para ejecutarse, siempre se ejecutará primero. Pueden tener dos tipos de políticas: Round Robin (en círculo) y FIFO (el primero en llegar es el primero en salir). En la planificación Round Robin, cada proceso de tiempo real ejecutable se ejecuta por turnos, y en la planificación FIFO cada proceso ejecutable se ejecuta en el orden que están en la cola de ejecución y el orden no se cambia nunca. Ø priority: Esta es la prioridad estática que el planificador dará a este proceso. También es la cantidad de tiempo que se permitirá ejecutar a este proceso una vez que sea su turno de ejecución. La prioridad de un proceso puede ser modificada. Ø rt_priority: Linux soporta procesos de tiempo real. Éstos tienen una prioridad más alta que todos los demás procesos en el sistema. Este campo permite al planificador darle a cada proceso de tiempo real una prioridad relativa. La prioridad del proceso se puede alterar mediante llamadas de sistema. Ø time_slice: Es el llamado quantum o rodaja de tiempo. Representa la cantidad de tiempo que se permite ejecutar este proceso en la CPU. Se decrementa a cada paso de reloj. Su valor inicial es asignado según la prioridad. La planificación en Linux se lleva a cabo en la función schedule() del fichero kernel/sched.c. El principal objetivo es el cambio de contexto, seleccionando un proceso de la lista de ejecutables y asignándolo a una CPU. Un cambio de contexto puede ocurrir por varios motivos: Ø Una señal bloqueante. Ø Finalización del proceso en ejecución. Ø El quatum o rodaja de tiempo asignada al proceso actual se consuma. Ø Se despierte un proceso cuya prioridad es mayor que la del proceso actual. Se definen dos punteros de descriptores de procesos: prev y next. El primero representa el proceso que va a dejar la CPU, el current, y el segundo, el que va a ser elegido para entrar a ejecutarse. La función que se encarga de decidir cuál es el siguiente proceso que pasará a ejecutarse es pick_next_task(). Una vez seleccionado el proceso de mayor prioridad de la runqueue correspondiente, se procede al cambio de contexto mediante la llamada a otra función, context_switch(). En el caso de que next y prev coincidieran no se produciría ningún cambio de contexto. Otra de las funciones que es importante comentar debido a su relación directa con el proyecto es scheduler_tick(). Se invoca en cada tick de reloj y se encarga 14 INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA

25 Capítulo 2: Modificación del Kernel GNU- Linux de disminuir el contador de la fracción de tiempo del proceso actual, y comprobar si el quantum se ha agotado. Además realiza balanceado para asegurar que las colas de ejecución de las diferentes CPUs contienen aproximadamente los mismos procesos ejecutables. 2.4 MODIFICACIONES Al utilizar la modulación, la mayor parte del código será implementado en los distintos módulos de las diferentes arquitecturas. Definiendo una interfaz en el kernel se consigue enlazar éste con los módulos, introduciendo las llamadas a las funciones en partes muy concretas del kernel y definiéndolas en el módulo correspondiente. Dadas las escasas modificaciones realizadas y la similitud de los sistemas operativos a la hora de crear, planificar y finalizar procesos, la integración en otros sistemas no es muy diferente de la realizada. La idea principal de la herramienta que se ha desarrollado es conseguir que un proceso padre monitorice a su hijo, siendo éste el programa deseado por el usuario. Para ello el hijo tiene que ser capaz de activar y desactivar los contadores y almacenar sus valores, y el proceso padre, poder leer dichos valores y monitorizarlos. Esto es posible añadiendo nuevos campos en el descriptor de proceso o estructura task_struct. Ø int prof_enable: Inicialmente toma valor 0, es decir, cuando este proceso tome el control de la CPU los contadores están desactivados. En el caso de querer activar los contadores este valor tendrá que ser modificado a 1. Ø void *pmc: Al ser una estructura que está definida en el módulo por ser dependiente de arquitectura, dentro del task_struct será un puntero de tipo void. Esto es así porque al arrancar el sistema operativo éste no conoce su situación exacta hasta que el módulo no es instalado. La estructura se llama pmon_prof_t (ver subcapítulo 3.2 Implementación del módulo). En ella se almacenará la información necesaria para hacer posible la monitorización de los contadores. Conocidos los cambios realizados en el descriptor de procesos, la forma en que el kernel o el usuario puede acceder a ellas es a través de las funciones de la interfaz mencionada anteriormente. La estructura de dicha interfaz está definida en el archivo mc_experiment.h de la siguiente manera: INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA 15

26 Capítulo 2: Modificación del Kernel GNU- Linux typedef struct pmc_mc{ void* (*init_pmon_prof_t); int (*pmc_config_read); int (*pmc_config_write); int (*monitor_pmcs_read); int (*monitor_pmcs_write); int (*pmc_enable_read); int (*pmc_enable_write); void (*amp_save_callback); void (*amp_restore_callback); void (*amp_pmon_tick); void (*free_pmon_prof); } pmc_mc; Las funciones de lectura y escritura están relacionadas con los ficheros del /proc, por lo que tiene un tratamiento diferente. Este tema será explicado en el cuarto capítulo. La integración del resto de las funciones en el kernel serán desarrolladas a continuación. Sin embargo, una descripción más detallada de su implementación se llevará a cabo en el capítulo siguiente. Ø init_pmon_prof_t: Esta función se encarga de reservar memoria e inicializar la nueva estructura pmon_prof_t integrada en el descriptor del proceso cuando éste sea creando. Al principio de este capítulo se muestra los pasos a seguir durante la creación de un proceso. Dentro de la función do_fork se llama a la función copy_process, que recibe como parámetros de entrada la información necesaria del proceso padre que se va a duplicar. Una vez generado el nuevo task_struct, o descriptor del proceso hijo, se llama a sched_fork, que realiza la planificación del nuevo proceso asignándole una CPU. Este es el momento más adecuado para invocar esta función. Además, justo después de la llamada, también se inicializa la variable prof_enable a cero. static struct task_struct *copy_process(unsigned long clone_flags, unsigned long stack_start, struct pt_regs *regs, unsigned long stack_size, int user *child_tidptr, struct pid *pid, int trace) { struct task_struct *p;... p = dup_task_struct(current);... /* Performance monitoring counter */ p->pmc = init_pmon_prof_t(p); p->prof_enabled = 0; /* Perform scheduler related setup. Assign this task to a CPU. */ sched_fork(p, clone_flags);... } return p; 16 INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA

27 Capítulo 2: Modificación del Kernel GNU- Linux Ø amp_save_callback: Cuando se realiza un cambio de contexto y el proceso actual tiene activado los contadores (p->prof_enable = 1) es necesario salvar el valor de los contadores y detenerlos ya que el proceso va a ser expulsado de la CPU. Esta es la finalidad de amp_save_callback. Como ya sabemos, la función que se encarga de la planificación es el schedule, así que aquí es donde se incluirá la llamada a la función, justo antes del cambio de contexto (context_switch). Ø amp_restore_callback: Esta función realiza la tarea opuesta a la anterior. En este caso, el proceso que ha sido elegido para entrar al procesador es el que tiene activado los contadores. Por lo tanto, la función se encarga de restaurar los contadores y activarlos para que vuelvan a contar los eventos correspondientes. La situación en el kernel es similar a la de amp_save_callback. asmlinkage void sched schedule(void) { struct task_struct *prev, *next; unsigned long *switch_count; struct rq *rq; int cpu; need_resched: preempt_disable(); // Se desactiva el cambio de contexto cpu = smp_processor_id(); // Se obtiene el ID de la CPU actual rq = cpu_rq(cpu); // Cola de procesos asignada a la CPU rcu_note_context_switch(cpu); prev = rq->curr; // prev guarda el proceso actual... next = pick_next_task(rq);... // next es el nuevo proceso a ejecutar /* Performance monitoring counter */ if(prev->prof_enabled) amp_save_callback(prev->pmc, cpu); if(next->prof_enabled) amp_restore_callback(next->pmc, cpu); } context_switch(rq, prev, next); // Realiza el cambio de contexto... Ø amp_pmon_tick: En el caso de que la herramienta quisiera leer los contadores y el proceso no haya dejado la CPU por cualquier motivo, la lectura que se realizaría sería errónea. Hasta el momento, sólo se guardan los valores de los contadores cuando se realiza un cambio de contexto mediante la función amp_save_callback. La solución es salvar esos valores no sólo cuando salga el proceso de la CPU sino también cuando se produzca una interrupción de reloj. El sitio más conveniente de insertar esta función es en la llamada a la función scheduler_tick para reducir el contador de la fracción de tiempo del proceso en ejecución. INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA 17

28 Capítulo 2: Modificación del Kernel GNU- Linux void scheduler_tick(void) { int cpu = smp_processor_id(); struct rq *rq = cpu_rq(cpu); struct task_struct *curr = rq->curr; sched_clock_tick(); /* Performance monitoring counter */ if(curr->prof_enabled) amp_pmon_tick(curr->pmc, cpu); }... Ø free_pmon_prof: En la creación de los procesos se realiza una reserva de memoria del kernel en la función init_pmon_prof_t para almacenar toda la información relacionada con los contadores. Esa memoria tiene que ser liberada cuando el proceso haya finalizado. En el capítulo anterior (2.1.1 Finalización de procesos), se habla de la función do_exit que es invocada cada vez que un proceso llegue a su fin. Una vez llamada dicha función, quien se encarga de la liberación de recursos es release_task. Es aquí donde se insertará la función free_pmon_prof que se detallará más adelante. Estas son las modificaciones mas relevantes del kernel. Aparte de las descritas en este capítulo, existen otras funciones que sin ellas no sería posible la comunicación del kernel con el módulo a través de la interfaz anterior. Al instalarse o desinstalarse el módulo, hay que comunicarle al kernel que las funciones insertadas se encuentran definidas dentro del módulo. Además, cuando el módulo es instalado también es necesario generar las entradas del /proc que hacen posible la comunicación de la herramienta de monitorización con el sistema. Estás funciones, que se encuentran definidas en el archivo mc_experiment.c se llaman register_pmc_module y unregister_pmc_module. Por otro lado, qué pasaría si no hubiera ningún módulo instalado? Las nuevas funciones introducidas en el kernel no estarían implementadas en ningún sitio. Para evitar este problema, se definen también en el mc_experiment.c una función wrapper por cada una de las funciones de la interfaz. Estos wrappers consisten en comprobar si existe un módulo instalado, y por lo tanto la implementación de la función correspondiente, para así poder seguir con la ejecución. En el caso de no existir el módulo, la función no realizaría ninguna tarea. De esta manera se evitan que se produzcan fallos críticos en el sistema. 18 INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA

29 Capítulo 3: Módulos CAPÍTULO 3 MÓDULOS La arquitectura del kernel de Linux permite cargar y descargar extensiones al sistema operativo en forma de módulos sin tener que detener o reiniciar el sistema. Esto implica una serie de ventajas: Ø Facilita la depuración del código. Ø Disminuye el requerimiento de memoria del sistema. Ø Evita la reconstrucción un nuevo kernel monolítico cada vez que se quiera añadir un nuevo dispositivo. Ø Y todo ello desencadena una disminución considerable de tiempo y una mayor flexibilidad a la hora de trabajar. A demás de las ventajas que conlleva la utilización de módulos, también permiten uno de los objetivos de este proyecto: conseguir que la herramienta de monitorización de rendimiento sea portable a cualquier arquitectura. Su compilación es considerablemente más rápida y la depuración en tiempo real es mucho más eficaz e intuitiva. A lo largo del capítulo, se explicará la forma de instalar y desinstalar un módulo mediante línea de comandos. Su implementación estará enfocada a una arquitectura basada en el procesador Intel Core 2 Duo. La parte desarrollada para los procesadores AMD es análoga exceptuando el modo configuración ya que es dependiente del tipo y el número de contadores de cada arquitectura. INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA 19

30 Capítulo 3: Módulos 3.1 INSTALACIÓN Y DESINSTALACIÓN Una vez compilado el módulo y generado el archivo.ko, instalarlo y desinstalarlo no demora mucho tiempo. Los comandos utilizados para la gestión de los módulos son los siguientes: Ø insmod: Seguido del paquete generado tras la compilación del módulo (.ko), inserta el módulo en el kernel. Ø rmmod: Seguido en este caso del nombre de un módulo previamente instalado, lo elimina del kernel. Ø lsmod: Lista todos los módulos instalados en el kernel actual. El módulo debe cumplir unos requisitos estructurales. Se utilizan unas macros definidas en el archivo <linux/init.h>. Éstas son module_init() y module_exit(). Ambas reciben por parámetro una función que inicializará o liberará los recursos del módulo. Por otra parte, podemos incorporar información como el autor, la licencia, la tabla de dispositivos, una descripción, etc. Basta con importar el archivo <linux/module.h> que define las macros correspondientes. 3.2 IMPLEMENTACIÓN Cómo vimos en el capítulo anterior, al instalar nuestro módulo se crean las entradas del /proc y se establece el enlace de las funciones declaradas en la interfaz con las del módulo. Otra función añadida es la configuración inicial de los contadores hardware, tanto los fijo como los configurables, asignado unos eventos por defecto. Ø Contadores fijos: En la arquitectura del Core 2 Duo son tres, y los eventos asignados son fijos y no pueden ser modificados por el usuario ( instrucciones por ciclo, ciclos de reloj y ciclos de bus ). Ø Contadores configurables: Son dos y en este caso el usuario sí que puede asignarle cualquier evento según lo que se desee contar. Por defecto, los eventos de estos contadores son fallos de la caché L2 y accesos de la caché L2, coincidiendo este último con los aciertos de la caché L1. Dentro del módulo se definen las estructuras utilizadas para hacer posible la monitorización de un proceso. La primera que vamos a describir es pmon_prof_t. Esta estructura ha sido la más complicada de desarrollar, sobretodo a la hora de integrarla en el descriptor de proceso (campo pmc del task_struct). 20 INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA

31 Capítulo 3: Módulos typedef struct{ atomic64_t ll_acum[max_ll_exps]; struct task_struct *parent_tsk; struct task_struct *child_tsk; int ticks_counter; unsigned int pmc_ticks_counter; uint_t ticks_last_pmc_read; int ticks_warm_up; unsigned int samples_counter; unsigned int switch_out_counter; unsigned int switch_in_counter; } pmon_prof_t; El significado de cada una de la variables es el siguiente: Ø ll_acum: Vector de MAX_LL_EXPS elementos, tantos como contadores de rendimiento posea la arquitectura. Guarda el valor de los contadores cada vez que haya una interrupción de reloj o un cambio de contexto. MAX_LL_EXPS es una macro definida para cada una de las arquitecturas que representa el número de contadores fijos y configurables. Para el Core 2 Duo es de valor 5 (3 contadores fijos y 2 configurables). Ø parent_task: Como hemos visto en el capítulo anterior, tras la ejecución de un fork se genera un proceso hijo como copia idéntica del proceso en ejecución, el proceso padre. Esta variable es un puntero que, en el caso de pertenecer al proceso hijo, hará referencia a su padre; en cualquier otro caso tomará un valor nulo. Ø child_task: Análogo a la variable parent_task, en el caso de pertenecer al proceso padre, ésta hace referencia al descriptor de proceso del hijo; en cualquier otro caso tomará un valor nulo. Ø ticks_counter: Número de ticks del contador transferidos a lo largo de la vida del proceso asociado. Ø pmc_ticks_counter: Acumulador de ticks necesarios para realizar la lectura de los contadores. Cuando llegue al valor permitido, se leerán los valores y se pondrá de nuevo a 0. Ø ticks_warm_up: Periodo por defecto de preparación previa al conteo real de los contadores. Ø samples_counter: Número de intervalos de muestreo. Ø switch_out_counter: Número de veces que el proceso ha sido expulsado de la CPU. Ø switch_in_counter: Número de veces que el proceso haya tomado la CPU desde la cola de prioridad. Otra de las estructuras dependiente de arquitectura es pmon_config_t. Su función es la de identificar si las muestras de los contadores son validas o no según el momento INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA 21

32 Capítulo 3: Módulos en el que se encuentre el proceso. Por ejemplo, durante el proceso de calentamiento de los contadores, los valores no serían correctos. Inicialmente, esta estructura tomará unos valores por defecto que podrán ser modificados por el usuario a través de una escritura en el fichero mod_pmc_config del procfs como veremos en el capítulo siguiente. Anteriormente se dieron a conocer algunas de las funciones más importantes del módulo. Sus objetivos y su situación dentro del kernel ya son conocidas, pero en este capítulo las conoceremos con más detalle. Al crear un proceso, la reserva de espacio de memoria en el kernel para la estructura pmon_prof_t se hace en una variable local dentro de la función init_pmon_prof_t mediante la siguiente línea de código: pmon_prof_t *prof = (pmon_prof_t*)kmalloc(sizeof(pmon_prof_t), GFP_KERNEL); En el caso de que existiera algún problema para reservar el espacio indicado, la función kmalloc nos devolvería un error que se captaría para informar al usuario. Por el contrario, si el funcionamiento fuera correcto, se inicializarían los campos de la variable prof, devolviendo su referencia para que la variable pmc insertada en el task_struct del proceso (ver subcapítulo 2.3 Modificaciones del kernel) apunte al espacio de memoria reservado para esta variable local. La memoria del kernel no es infinita, por lo que de la misma forma que se reserva espacio cuando se crea un proceso hay que asegurarse de su liberación a la finalización de mismo. La liberación de la estructura pmon_prof_t de un proceso se realiza en la función free_pmon_prof que recibe por parámetro el task_struct del proceso en cuestión. El código que se encarga de la eliminación completa de la estructura es el siguiente: kfree((pmon_prof_t*)tsk->pmc); tsk->pmc = NULL; Antes de la liberación, debemos tener cuidado con las referencias entre padre e hijo por medio de los campos parent_task y child_task definidos más arriba, ya que dejar un puntero asignado a un espacio de memoria inexistente puede dar lugar a un error critico en el sistema. PARENT PROCESS parent_task child_task CHILD PROCESS Figura 3.1: Liberación de un proceso hijo 22 INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA

33 Capítulo 3: Módulos La asignación de parent_task y child_task las realiza la aplicación desarrollada por medio de una escritura en el fichero mod_monitor_pmcs del procfs (ver subcapítulo 4.3). La idea es que como el proceso hijo conoce a su creador, éste acceda a él a través de parent_task y ponga el campo de child_task a null antes de su liberación. Por último, se hablará de la función que se encarga de salvar los valores de los contadores para su posterior lectura: do_count_mc_experiment. Como ya se dijo en el capitulo anterior, los contadores son guardados cuando se produce un cambio de contexto llamando a amp_save_callback, o simplemente en cada interrupción de reloj con amp_pmon_tick. Pues bien, ambas funciones, para realizar dicho guardado, utilizan do_count_mc_experiment. Inicialmente, se comprueba si realmente las muestras se quieren guardar o no; es decir, no seria necesario salvar el valor de los contadores si éstos se encuentran en la preparación previa al conteo real o, simplemente, no interese salvarlos en ese preciso instante. Posteriormente, cuando todo indique que los valores de los contadores son correctos y se quieran guardar, se paran los contadores, se realiza una lectura de los mismos y se establece de nuevo su funcionamiento. Por último, se obtienen los valores leídos para acumularlos en el vector de resultados de los contadores ll_acum definido en la estructura pmon_prof_t. for(i=0; i<cur_ll_set->size; i++){ low_level_exp* lle = &cur_ll_set->array[i]; stop_count(lle); read_count(lle); start_count(lle); // Parada de los contadores // Lectura de sus valores // Reanudacion de los contadores /* Obtenemos el ultimo valor leido */ last_value = get_last_value(lle); } rcu_read_lock(); atomic64_add(last_value, &prof->ll_acum[i]); rcu_read_unlock(); Como se puede observar, la variable ll_acum es de tipo atomic64_t. Las operaciones atómicas son el método de sincronización entre procesos más eficiente puesto que se realizan a muy bajo nivel. Consiste en ejecutar operaciones sobre un entero en un único paso indivisible, sin admitir interrupciones. Con ello nos aseguramos que el proceso padre no pueda leer esta variable mientras que se esté actualizando su valor. Quedaría bloqueado mientras que la operación atómica atomic64_add no haya terminado. La lectura de la variable ll_acum y su posterior restauración se realiza a través del fichero mod_monitor_pmcs del procfs explicado en el capitulo siguiente. INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA 23

34

35 Capítulo 4: Sistema de ficheros PROCFS CAPÍTULO 4 SISTEMA DE FICHEROS PROCFS En Linux existe un mecanismo para que el kernel y los módulos puedan intercambiar información con los procesos en ejecución, el sistema de ficheros procfs (process filesystem). Es un pseudo- sistema compuesto por un conjunto de archivos virtuales, generalmente montados en el directorio /proc, que se generan cada vez que se inicia el equipo. Estos archivos no existen físicamente en el disco, sino que se encuentran alojados en la memoria principal de la máquina. En este capítulo abordaremos las entradas en este sistema de ficheros que han sido creadas para hacer posible la comunicación entre la herramienta desarrollada y el módulo. INTERFAZ DE USO DE CONTADORES HARDWARE MULTIPLATAFORMA 25