2 SOs distribuidos, multiprocesadores y multicomputadores Diseño de Sistemas Operativos (cc) José Antonio Gómez Curso 2013-14
Introducción Sistemas Operativos I y II están dedicadas básicamente a sistemas monoprocesadores. En este tema, abordaremos los principales problemas y soluciones de los SOs cuando gestionamos: Sistemas distribuidos Multipocesadores Multicomputadores 2
Tipos de DOS Sistemas Operativos Distribuidos (DOS): SO's fuertemente acoplados para multiprocesadores y multicomputadores homogéneos Objetivo principal: gestionar y esconder los recursos Sistemas operativos de Red (NOS): SO debílmente acoplado para multicomputadores homogéneos Objetivo básico: ofercer servicios a los clientes remotos. Middleware: Capa sobre un NOS que implementa servicios de propósito general Objetivo: suministrar transparencia de distribución 3
Tipos de DOS (y ii) (1) (1) Tanenbaum, Van Steen, Distributed Operating Systems, Prentice Hall, 1998 4
Características de los sistemas Item Sistemas operativos distribuidos MultiprocesadorMulticomputador NOS Grado de transparencia Muy alto Alto Bajo Mismo SO en nodos Si Si No Nº copias del SO 1 N N Memoria compar. Comunicación Mensajes Archivos Gestión de recursos Global, central Global, distribuida Por nodo No Moderada Si Escalabilidad Apertura Cerrado Cerrado Abierto Middleware SO Alto No N Específico Por nodo Varia Abierto 5
Comunicación en DOS RPCruntime Kernel Call Servidor Return Tocón cliente Call Desempaquetado de parámetros Tocón servidor Empaquetado de parámetros Cliente Visión de alto nivel: El proceso llamador (cliente) se suspende. Los parámetros del procedimiento se pasan al proceso llamado (servidor). El servidor ejecuta el procedimiento, y devuelve los parámetros de retorno. Se reanuda al llamador. Return RPCruntime Kernel Red 6
RPC: paso de parámetros Empaquetado de parámetros (marshaling) - el tocón cliente empaqueta los parámetros en un mensaje. Desempaquetado de parámetros (unmarshaling) - el tocón servidor desempaqueta los parámetros para una llamada a procedimiento local. Manejo de diferentes representaciones de datos: ASCII, EBCDIC; complemento a 1, a 2, punto flotante; big endian y little endian. Se establece una forma canónica de representación de datos, p. ej. XDR (extended Data Representation). 7
RPC: paso de parámetros Un procedimiento remoto no puede acceder a variables globales debe pasar los datos en la llamada. Llamada por valor (el procedimiento obtiene una copia de los datos) - se pasan parámetros en el mensaje. No se pueden realizar llamadas por referencia (procedimiento obtiene un puntero a los datos). En su lugar, realiza llamada por copia - en lugar de un puntero se pasa el item al que apunta, el procedimiento lo modifica y lo devuelve. Se producirán inconsistencias si el cliente no se bloquea. 8
RPC: Generación de tocones C/C++ no son lo suficientemente expresivos para generar los tocones automáticamente: no expresan qué parámetros son de entrada, de salida, de e/s; tamaño exacto de los parámetros; que significa pasar un puntero. Necesitamos un lenguaje de definición de interfaces (IDL) para la especificación de las signaturas del procedimiento para poder generar los tocones. Ventaja: Hay herramientas que compilan la especificación y generan los tocones, p. ej. rpcgen de Sun. 9
RPC: generación de tocones (ii) 10
RPC: autenticación RPC utiliza 5 mecanismo de autentificación: AUTH_NULL sin autentificación AUTH_UNIX credenciales estilo Unix: nombre màquina cliente, UID y GID. AUTH_SHORT devuelta por el servidor tras una AUTH_UNIX para posteriores peticiones. AUTH_DES autentificación segura utilizando claves privadas AUTH_KERB idem utilizando Kerberos. 11
Servidores Servidor con estado: mantiene información de estado de cada cliente y archivo. Orientado a la conexión (abrir archivo, leer/escribir, cerrar) Permite optimizaciones del servidor como lectura adelantada y bloqueo de archivos. Es difícil recuperar el estado después de una caída. Servidor sin estado: no mantiene esa información Cada solicitud es autocontenida (archivo, posición, acceso). No orientado a conexión (abrir y cerrar están implicadas). Si el servidor cae, los clientes simplemente repiten las solicitudes hasta que se recupere. No optimizaciones del servidor. Ciertas operaciones idempotentes. 12
Ligadura La ligadura es la operación para determinar el servidor y el procedimiento remoto a llamar. Ligadura en compilación - la dirección del servidor(es) está empotrada en el código. Es inflexible si el servidor cambia de ubicación, o existen múltiples copias de un servidor. Ligadura en tiempo de enlace - el cliente solicita un handle antes de utilizar el servicio. Ligadura en tiempo de llamada - el cliente se liga al servidor en la primera llamada. 13
Establecer la ligadura Servidor de directorios Dirección del servidor o handle al servidor Binder/trader/broker 2 Cliente Máquina cliente create 3 # puerto 4 Handle cliente Registro de servicio Port Mapper 1 Servidor Registra programa, versión y puerto Máquina servidor 14
Ejemplo: NFS Network File System (NFS) Sistema de archivos que permite a un usuario almacenar sus archivos en máquinas de una red. Un servidor NFS exporta sistemas de archivos a sus clientes. Un cliente NFS monta sistemas de archivos remotos como si fuesen locales. Ambos utilizan el protocolo NFS construido sobre RPC. 15
FS locales y remotos Server 1 Client (root) (root) export people big jon bob...... vmunix Server 2 (root) usr nfs Remote mount Remote students x staff users mount jim ann jane joe 16
NFS Versión 4: requisitos Acceso mejorado y buen rendimiento sobre Internet. Seguridad fuerte, con negociación de la seguridad construida en el protocolo. Interoperatividad mejoradad entre plataformas cruzadas. Extensibilidad del protocolo. 17
NFS v.4: características Nuevas características de NFS v.4 (RFC 3530): Estado de seguimiento de archivos (bloqueo, lectura y escritura). Bloqueo basado en leasing Delegación de archivos. Seguridad: RPCSEC_GSS, krb5, SPKM3) ACLs Protocolos unificados: stat, NLM, ACL, NFS Migración y replicación de archivos Extensibilidad 18
NFS: reducción del tráfico Dos mecanismos: RPC compuesta (compound): permite múltiples llamadas RPC embebidas en una misma petición. Garantía de la consistencia de las cachés de los clientes mediante las operaciones de delegación sobre archivos regulares. Similar al bloqueo de archivos (diferencias: se delega en un cliente, no en procesos particulares; el bloqueo es solicitado por los clientes; la delegación puede ser reclamada por el servidor en cualquier instante) 19
NFSv4: servidor con estado A diferencia de las versiones anteriores, NFSv4 es un servidor con estado: Las operaciones de bloqueo de archivos son parte del protocolo NFS, eliminando la necesidad de los demonios rpc.statd y rpc.lockd. El estado esta basado en arrendamiento (leasebased): este expira si el cliente no realiza operaciones que manipulan el estado dentro del servidor durante el periodo de usufructo. Un cliente puede renovar el estado con RENEW. 20
Estado de NFSv4 Constituyen en estado: Identificador de cliente: clientid. Lockowner: existe un lockowner por proceso en el cliente. Tiene tres significados: Unidad de contención para cerrojos. Unidad de serialización: OPEN, CLOSE ylock son serializadas en base al lockowner (el cliente antes de enviar la operación N+1ésima, debe esperar a que la N-ésima finalice. Unidad de propiedad del archivo abierto: un archivo puede ser abierto como máximo una vez por cada lockowner. Identificador del estado (stateid): cada stateid identifica un archivo abierto (parecido a un descriptor de archivo) y es necesario para las operaciones de manipulación del archivo. 21
RPC compuesta Esta RPC subsume todas las operaciones previas excepto el procedimiento NULL. Su procesamiento no es atómico, se serializa, y para en la primera operación que de error. Implicación: no podemos implementar la cache de respuesta en el dispatcher rpc. La capa RPC no saber que procedimiento se esta procesando (solo hay 1), por lo que el procesamiento descansa en la capa XDR. 22
NFS v4: Delegación Cuando un cliente abre un archivo, el servidor retorna al cliente: Delegación de lectura: garantía de que ningún otro cliente ha abierto el archivo de escritura, por lo que el cliente puede cachear los datos sin necesidad de chequeos de consistencia. Delegación de escritura: garantía de que ningún otro cliente ha abierto el archivo de ninguna forma, por lo que es libre de diferir o agrupar las escrituras en el servidor. Un cliente no puede ni solicitar ni rehusar delegaciones, pero puede retornar una delegación a su elección. 23
NFS: operaciones por versión 24
NFS: Arquitectura 25
NFS: uso Servidor: En /etc/exports añadir los directorios a exportar y los clientes autorizados. Abrir el puerto TCP 2049 en el firewall Ejecutar /etc/init.d/nfs restart y chkconfig level 345 nfs on Cliente: Ejecutar mount -t nfs4 -o rw,intr,hard server:/ /mount/point 26
Enlaces Mailing list - nfsv4@linux-nfs.org NFSv4 website - http://linux-nfs.org Bug tracker - http://bugzilla.linux-nfs.org Wiki - http://wiki.linux-nfs.org 27
Referencias W. A. Adamon, y K.M. Smith, Linux NFS Versión 4: Implementation and Administration, Proceeding of the 2001 OSL (Otawa Linux Symposium), July 25th-28th, 2001, Ottawa Canada. B. Callaghan, NFS Illustrated, Addison-Wesley, 2000. B. Pawlowski, et al., The NFS Version 4 Protocol, Proceeding of the 2nd SANE (System Administration and Network Engineering) Conference, May 22-25, Maastricht, The Netherlands 2000. 28
Innovaciones en NFS PNFS (parallel NFS) FS de escalado y rendimiento altos. pnfs separa la capa de datos de los propios datos, permitiendo una arquitectura de camino-dual. 29
Alternativas a NFS En sistemas Windows: CIFS (Common Internet File System) o también conocido como SMB (Server Message Block). En Linux, Ceph: sistema de archivos distribuido tolerante a fallos de alto rendimiento y escalabilidad. 30
Ceph: objetivos Sistema de archivos que pretende: Escalabilidad (> petabytes) Alto rendimiento Fiabilidad Disponibilidad Desacopla: Datos y metadatos Gestión de metadatos distribuidos dinámica Almacenaje de objetos distribuidos autónomo fiable. 31
Ceph: componentes Object Storage Devices (OSD): los discos son reemplazados con dispositivos con CPU, interfaz de red, caché local y disco o RAID. Separa las funciones de datos y metadatos eliminando las tablas de asignación de archivos, sustituyéndolas por funciones generadoras CRUSH. Un Servidor de MetaDatos (MDS), que gestiona espacios de nombres (nombres de archivos y directorios). Los clientes, que interaccionan con un MDS para realizar las operaciones de metadatos (open, rename, etc.), mientras que se comunica directamente con OSD para las operaciones de E/S (read, write). 32
Ceph: arquitectura Fuse (Filesystem in UserSpacE) sistema de archivos que permite al usuario crear sistemas de archivos virtuales sin modificar el núcleo 33
Ceph: Dynamic Subtree Partitioning Este mecanismo distribuye de forma inteligente y adaptativa la responsabilidad de manejar la jerarquía de directorios entre decenas/cientos de MDS 34
Ceph: distribución de datos con CRUSH CRUSH (Controlled Replication Under Scalable Hashing)- Función de distribución de datos seudo-aleatoria que mapea eficientemente cada PG (Placement Group) en una lista ordenada de OSD sobre los que almacenar replicas de objetos. 35
Ceph: enlaces y referencias http://ceph.sourceforge.net S.A. Weil, et al., Ceph: A Scalable, HighPerformance Distributed File System, th Proceeding of the 7 USENIX Symposium on Operating Systems Design and Implementation (OSDI'06), pgs. 307-320, 2006. 36
Otros servicios distribuidos Namespaces en Linux permite construir mecanismos ACR (Application Checkpoint and Restart) sobre los que desarrollar sistemas de migración de computación. Algunos ejemplos: Zap OpenVZ VServer MCR 37
Diferentes necesidades, sistemas diferentes Sistemas Operativos de Internet (Cloud computing): WebOS, EyeOS,... SO para computación móvil: Linux mobile, Windows mobile, SymbiamOS, PalmOS,... SO para computación ubícua: PlanB, TinyOS,.. SOs para multi-computadores/procesadores: Multinúcleo (Multicore) SMP (Simmetric MultiProcessing) NUMA (Non-Uniform Memory Access) 38
Computación penetrante o ubícua* Comunicaciones remotas capas de protocolos, RPC, args end-to-end,.. Tolerancia a fallos ACID, transacciones anidadadas,... Sistemas Distribuidos Computación móvil Computación penetrante Alta disponibilidad Replicación, recuperación rollback Acceso a información remota Sists, archivos distribuidos, BDs, caches Seguridad distribuida Espacios inteligentes Encriptación, autenticación mutua,... Redes móviles Empotrar computación en construcción Invisibilidad IP mobiles, redes ad hoc, TCP wireless,... Acceso a la información móvil Operaciones desconectadas, consistencia débil,... Aplicaciones adaptativas Transcoding proxies, gestión adaptativa de recursos,... Sistemas energy-aware Adaptación dirigida por objetivos, discos con parada,... Sensibilidad de ubicación Distracción mínina del usuario Escalabilidad localizada Reducir interacciones con la distancia Acondicionado irregular Reducir las variaciones vistas por el usuario GPS, conciencia del contexto,... * Extraido de [Sataylayout2001] 39
Cloud Computing Modelo que permite un acceso conveniente y bajo demanda de red a una bolsa de recursos de computación configurables (redes, servidores, almacenamiento, aplicaciones y servicios) que pueden suministrase de forma rápida y liberarse con un mínimo esfuerzo de mantenimiento o interacción con el suministrador de servicios [National Institute of Standards and Technology]. No es una nueva tecnología, sino un nuevo modelo de operación de tecnologías existentes. 40
Arquitectura cloud-computing SaaS = suministra aplicaciones bajo demanda sobre Internet PaaS = suministra recursos de plataforma, incluido soporte de SO y framework de desarrollo software IaaS = suministra recursos de infraestructura bajo demanda, usualmente en términos de VM. Extraida de Qi Zhang, Lu Cheng y Raouf Boutaba, Cloud computing: stateof-the-art and research challenges, Internet Services and Applications, Vol. 1, No. 1, pp. 7-18, May 2010. 41
Cloud Operating Systems Cloud SO = tipo de SO diseñado para operar en entornos de computación en nube y virtualizados, que gestiona las operaciones, ejecución y procesos de las máquinas virtuales, servidores virtuales e infraestructura virtual, además de hardware del servidor y los recursos software. También se puede denominar como sistemas operativo virtual, sistema operativo de internet, webos. El SO de la nube gestiona diferentes servidores y dispositivos hardware, dando la impresión a los usuarios de que están interaccionando con una nube de infinita capacidad y elasticidad. 42
Modelo lógico de un Cloud OS Extraída de F. Pianes et al., Toward a Cloud Operating System, Network Operations and Management Symposium Workshops (NOMS Wksps), pages 335-342, IEEE/IFIP, 19-23 April, 2010. 43
Elementos del modelo Objeto nube (CO)= conjunto de procesos locales que se ejecutan en un único nodo, que estan epaquetados juntos y con un mismo identificador. Proceso nube (CP) = colección de COs que implementan la misma aplicación (distribuida). Espacio kernel nube = CPs que regulan la asignación física, control de acceso, contabilidad, y medida de los recursos. Aplicaciones de usuario = CPs ejecutadas directamente por el usuario que interacciona con las bibliotecas de la nube o el kernel a través de una interfaz de llamadas al sistema de la nube. La asociación entre nombres de objetos y sus direcciones de red y puertos es mantenida por el gestor de procesos y la gestión de MV y la información resultante se hace disponible a la nube vía la biblioteca de naming. La biblioteca de nombres mantiene también la relación entre los CPs de la aplicación de usuario y los objetos que la componen. Autentificación = verifica y otorga las operaciones de gestión. Los CPs de medida están siempre activos y operan tanto bajo demanda como de fondo. 44
Sistemas Operativos para la nube Sistemas operativos actuales: Cloud Operating Systems: VMware vsphere 4 Ubuntu Enterprise OS Web-Based Cloud Operating Systems: icloud eyeos Glide OS g.ho.st 45
Sistemas Operativos de Internet (IOS) Idea simple pero cierta: la red, o Internet, se ha convertido en el computador. Ahora es posible ensamblar una aplicación a partir de componentes denominados servicios Web. Cambio de modelo de aplicación: el modelo IOS permite combinar la facilidad de uso y mantenimiento de una aplicación web con las ventajas de integración disponible en aplicaciones nativas. Difumina la interfaz del SO 46
Componentes de un IOS Vamos a comparar los componentes tradicionales de un SO y computador con los componentes del IOS: CPU Sistema de archivos Jerarquía de memoria Mensajes Directorios Seguridad... 47
IOS: CPU Internet puede verse como un multiprocesador distribuido y másivamente paralelo. Tenemos dos extremos: Computación Grid una tarea puede descomponerse el múltiples hebras y ejecutarse en paralelo en múltiples computadores de la red. Por ejemplo, WebOS, Legion, GoogleOS, etc. Sistemas peer-to-peer donde existe poca o nula coordinación entre los nodos. Por ejemplo, Napster, Gnutella, SETI@Home, etc. 48
IOS: Almacenaje de archivos El sistema de archivos de Internet consta de los dispositivos de almacenamiento de numerosos computadores conectados a la red. Podemos tener particiones del disco gestionadas por aplicaciones distribuidas. Ejemplo, devfs2 es un manejador de disco de Linux que soporta el sistema de archivos WebDAV (estándar XML define cómo se gestionan los archivos y carpetas en Internet y en las plataformas J2EE y.net) 49
IOS: Jerarquía de memoria Actualmente, el único elemento similar a una jerarquía de memoria es la caché del navegador web. Esta caché es pequeña comparada con la cantidad de información a almacenar -> muchas faltas de cache -> es necesario, aumentar la jerarquía. Content Delivery Network (CDN), como Akami, Exodus,... mantienen caches intermedias en servidores próximos. El cacheado, replicación y entrega de contenidos es un área en desarrollo. 50
IOS: Mensajería La composición de servicios basados en WEB para construir aplicaciones de Internet debe basarse en mecanismo de comunicación estándares como HTTP, XML, y SOAP, para que esos componentes puedan intercambiar datos y servicios de forma fácil. 51
IOS: Directorios Una aplicación basada en web debe ser capaz de localizar dos tipos de recursos distribuidos: datos (contenidos información estructurada) y servicios. Se requieren dos tipos de directorios: Directorios de contenidos no hay estándar, puede utilizarse WebDAV. Directorios de servicios UDDI es un estándar para este tipo de directorio. 52
IOS: Seguridad Requiere la misma lista de servicios de seguridad que los SOs de servidores, la diferencia es la escala: gestión de perfiles de usuarios, autenticación, autorización, comunicaciones seguras, única firma para varias aplicaciones. Por ejemplo, Microsoft Passport es un mecanismo de firma única para aplicaciones del portal MSN. 53
Ejemplo: Esta basado en un kernel 2.6 de Linux, con una combinación componentes Palm que suministran servicios a nivel de usuario (CoreOS: kernel de Linux, manejadores, servicios del SO, Middleware, wireless, y subsistema de medios). El usuario no interacciona con CoreOS sino con el Entorno de Aplicación (aplicaciones y UI System Manager) 54
Arquitectura de Palm webos API de WebOS (Framework JavaScript) Core OS Figura extraída de M. Allen, Palm webos, O'Reilly, 2009 55
Sistemas Operativos en Cluster Grid computing = paradigma de computación distribuida que coordina recursos en red para alcanzar un objetivo computacional común. Diferencia con Cloud computing: ésta utiliza tecnologías de virtualización a múltiples niveles (hardware y plataforma de aplicación) para compartir y suministrar recursos de forma dinámica. Podemos diferenciar un cluster de un sistema grid, en que el primero es un sistema limitado en una red limitada. Un cluster permite: Equilibrio de carga Compensación de fallos Procesamiento paralelo 56
Planificación distribuida Un Linux estándar no tiene soporte para planificación distribuida (si para SMP, SMT y MC). Algunas soluciones: Beowulf Job Manager (BJM) Job= colección de PIDs ejecutándose en un nodo propiedad del mismo usuario. Cada usuario tiene una única cola de trabajos (permite controlar cuantas CPUs se le asignan a un usuario). Mosix/OpenMosix Permite equilibrio de carga apropiativo, acomodo de memoria, y optimización de E/S sobre archivos. Actúa de forma transparente. No suministra IPC. Migra contexto usuario (problemas con E/S). Maui Scheduler planificador batch para HPC. Permite reserva de nodos a grupos o usuarios. 57
Procesadores multi-core Múltiples procesadores independientes en un mismo IC que comparten algunos elementos (p. ej. cache L2, bus,..) Los núcleos pueden ser homogéneos o heterogéneos. 58
Soporte del SO a CMP Los SOs actuales tratan estos sistemas como multiprocesadores clásicos Problema: no se explotan al máximo las capacidades del sistema Los problemas se agravan en sistemas heterogéneos, donde el SO no los soporta totalmente de forma nativa, es decir, las aplicaciones deben gestionar directamente los núcleos. 59
Planificación de CMP Principal reto: identificar y predecir los recursos necesitados por cada tarea y planificar las tareas para minimizar la contención de los recursos compartidos, máximizar la utilización de recursos, y explotar las ventajas de los recursos compartidos entre los núcleos. Para ello el planificador debe ser consciente de: La existencia del múltiples núcleos Topología de los recursos Requisitos de las tareas Interrelación entre tareas 60
Planificación en multiprocesadores El kernel 2.6 de Linux soporta planificación en sistemas SMT, SMP y NUMA Introduce el concepto de dominios de planificación que incorpora información de la topología en el planificador. Un dominio de planificación contiene una lista de grupos de planificación que tienen propiedades comunes. En cada nivel de dominio se ejecuta un equilibrador de carga. Las propiedades del dominio dictan el equilibrado entre grupos de planificación en ese dominio. 61
Dominios de planificación Sistema NUMA con procesadores SMT: 3 dominios de planificación Proximidad de memoria + 62
Implementación Los parámetros de planificación se almacenan en las estructuras sched_domain y sched_group 63
Implementación (ii) El planificador intenta mantener la carga del sistema lo más equilibrada posible, ejecutando el re-equilibrado cuando se producen ciertos eventos de re-equilibrado, o mediante equilibrado activo (periódico). La política de eventos de equilibrado es específica de cada dominio. Clave: afinidad. El equilibrado activo es más simple, e intenta evitar que procesos acotados por CPU consuman todos los ciclos de un procesador. 64
Equilibrio de carga iter_move_one_task coge una tarea de la cola de ejecución (rq) más ocupada y la encola en la CPU actual. load_balance permite distribuir múltiples tareas desde la rq más ocupada a la CPU actual, pero no más de la especificada en max_load_move. Activación 65
Gestión de potencia Un aspecto importante a considerar en los diseño actuales es la gestión de potencia, encaminada a mantener la potencia de cómputo reduciendo: Los costes de consumo de energía Los costes de refrigeración Esta gestión se puede realizar a varios niveles: Nivel de CPU: P-states, C-states y T-states. Nivel de SO: CPUfreq (paquetes cpufrequtils y cpupower) y planificación 66
Especificación ACPI Advanced Configuration and Power Interface: especificación abierta para la gestión de potencia y gestión térmica controladas por el SO. Desarrollada por Microsoft, Intel, HP, Phoenix, y Toshiba. Define cuatro estados Globales (Gestados): G0: estado de funcionamiento: estados-c y estados-p G1: estado dormido S-estados G2: Estado apagado soft G3: Estado apagado mecanico Techarp, PC Power Management Guide Rev. 2.0, disponible en http://www.techarp.com/showarticle.aspx?artno=420 67
Estados de la CPU S-estados: estados dormidos en G1. Van de S1 a S5. C-estados: estados de potencia en G0. C0:activo, C1:halt, C2:stop, C3, deep sleep,... P-estados: relacionados con el control de la frecuencia y el voltaje del procesador. Se usan con G0 y C0. P1-Pn, a mayor n menos freq y volt. T-estados: estados throttles relativos a la gestión térmica. Introducen ciclos ociosos. ACPI spec v5.0, Dic. 2011 68
Infraestrucutra CPUfreq El subsistema CPUfreq es el responsable de ajustar explícitamente la frecuencia del procesador. Estructura modularizada que separa políticas (gobernadores) de mecanismos (drivers específicos de CPUs). Gobernadores a nivel usuario Gobernadores en el kernel Powersaved Performance Powersave cpuspeed Userspace Conservative Ondemand Módulo CPUfreq (interfaces /proc y /sys) Drivers específicos De CPU acpi-cpufreq speedstep-centrino Powernow-k8 Driver ACPI del procesador 69
Gobernadores Performace mantiene la CPU a la máxima frecuencia posible dentro un rango especificado por el usuario. Powersave mantiene la CPU a la menor frecuencia posible dentro del rango. Userspace exporta la información disponible de frecuencia a nivel de usuario (sysfs) permitiendo su control al mismo. On-demand ajusta la frecuencia dependiendo del uso actual de la CPU. Conservative Como 'ondemand' pero ajuste más gradual (menos agresivo). Podemos ver el gobernador por defecto en /sys/devices/system/cpu/cpux/scaling_governor 70
Herramientas Cpufrequtils podemos ver, modificar los ajustes del kernel relativos al subsistema CPUfreq. Las órdenes cpufreq* son utiles para modificar los estados-p, especialmente escalado de frecuencia y gobernadores. Cpupower ver todos los parámetros relativos a potencia de todas las CPUs, incluidos los estados-turbo. Engloba a la anterior. PowerTOP ayuda a identificar las razones de un consumo alto innecesario, por ejemplo, procesos que despiertan al procesador del estado ocioso. Se pueden crear perfiles en /etc/pm-profiler. 71
Planificación y energía En CMP con recursos compartidos entre núcleos de un paquete físico, el rendimiento máximo se obtiene cuando el planificador distribuye la carga equitativamente entre todos lo paquetes. En CMP sin recursos compartidos entre núcleos de un mismo paquete físico, se ahorrará energía sin afectar al rendimiento si el planificador distribuye primero la carga entre núcleos de un paquete, antes de buscar paquetes vacíos. 72
Algoritmos de planificación El administrador elige la política de planificación: entradas sched_mc_power_saving y sched_smt_power_saving de /sys/devices/system/cpu/. Esto básicamente desactiva el equilibrado de carga (ajuste estados-c). Rendimiento óptimo Ahorro de energía A partir del kernel 3.4, esta solución ha desaparecido y se están buscando otras alternativas. 73
Bibliografía HP, Intel, Microsoft, Phoenix, y Toshiba, Advanced Congiguration and Power Interface Specification Rev. 5.0, Dic. 2011, disponible en http://www.acpi.info/downloads/acpispec50.pdf Jenifer Hopper, IBM developerwork, 2009, Reduce Linux power consumpsion: Part 1: the CPUfreq subsystems. Part 2: General and Governor-specific settings. Part 3: Tuning result. Patrick Mochel, The state of Linux Power Management 2006, Proceeding of the Linux Symposium, vol 2, Ottawa 2006. OpenSuse, Chapter 11: Power Management, en opensuse 12.3: System Analisys and Tuning Guide, 2013, disponible en http://doc.opensuse.org/documentation/html/opensuse/opensusetuning/cha.tuning.power.html. 74
Planificación: grupos de control El planificador trata con entidades planificables: tareas o grupos de tareas. Esto permite definir grupos de planificación Diferentes procesos se asignan a diferentes grupos. El planificador reparte la CPU imparcialmente entre grupos, y luego entre proceso de un grupo. Esto reparte imparcialmente la CPU entre usuarios. 75
Grupos de control Suministran un mecanismo para: Asignar/limitar/priorizar recursos: CPU, memoria, y dispositivos. Contabilidad: medir el uso de recursos. Aislamiento: espacios de nombres separados por grupo. Control: congelar grupos o hacer checkpoint/restart. Los cgroups son jerárquicos: un grupo hereda los límites del grupo padre. 76
Subsistemas de grupos de control Existen diferentes subsistemas (controladores de recursos): cpu: utilizado por el planificador para suministrar el acceso de las tareas de un cgroup a la CPU. cpuacct: genera automáticamente informes de la CPU utilizada por las tareas de un cgroup. cpuset: asigna CPUs individuales y memoria en sistemas multi-core. devices: permite/deniega el acceso de las tareas a un dispositivo. freezer: detiene la ejecución de todos los procesos de un grupo. memory: limita el uso de memoria a tareas de un cgroup, y genera informes automáticos del uso de memoria de esas tarea. blkio: establece los límites de accesos de E/S desde/hacia dispositivos de bloques (discos, USB,...) net_cls: etiqueta paquetes de red con un identificador de clase (classid) que permite al controlador de tráfico (tc) identificar los paquetes originados en una tarea de un grupo. Ns: subsistemas de espacios de nombres (namespaces), visto en Tema 1, 77
Relaciones entre subsistemas, jerarquias, cgroups y tareas Definiciones: Tarea: proceso de usuario o kernel Cgroup: una o más tareas. Subsistema: modulo que modifica el comportamiento de las tareas de un cgroup. Jerarquía: varios cgroups en un árbol. Existen 4 reglas que gobiernan la relación entre subsistemas, jerarquías, grupos de control y tareas (procesos): 78
Regla 1: una única jerarquía puede tener uno o varios subsistemas ligados a ella Subsistema CPU Subsistema Memoria /cpu_mem_cg /cg_1 /cg_2 Jerarquía cgroup 79
Regla 2: Un subsistema ligado a una jerarquía A no puede ligarse a otra jerarquía B, si la B tiene un subsistema diferente ligado a ella Subsistema CPU Subsistema Memoria /cpu_cg /cpu_mem_cg /cg_1 /cg_3 /cg_2 /cg_4 Jerarquía cgroup A Jerarquía cgroup B 80