2 SOs distribuidos, multiprocesadores y multicomputadores

2SOs distribuidos,multiprocesadores ymulticomputadoresDiseño de Sistemas Operativos(cc) José Antonio GómezCurso 2013-14

Diseño de Sistemas Operativos - Tema 2 2Introducción• Sistemas Operativos I y II están dedicadasbásicamente a sistemas monoprocesadores.• En este tema, abordaremos los principalesproblemas y soluciones de los SOs cuandogestionamos:– Sistemas distribuidos– Multipocesadores– Multicomputadores

Diseño de Sistemas Operativos - Tema 2 3Tipos de DOS• Sistemas Operativos Distribuidos (DOS):– SO's fuertemente acoplados para multiprocesadores ymulticomputadores 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

Diseño de Sistemas Operativos - Tema 2 4Tipos de DOS (y ii)(1)(1) Tanenbaum, Van Steen, Distributed Operating Systems, Prentice Hall, 1998

Diseño de Sistemas Operativos - Tema 2 5Características de los sistemasItemSistemas operativos distribuidosMultiprocesadorMulticomputador NOS Middleware SOGrado de transparencia Muy alto Alto Bajo AltoMismo SO en nodos Si Si No NoNº copias del SO1 N N NComunicación Memoria compar. Mensajes Archivos EspecíficoGestión de recursos Global, central Global, distribuida Por nodo Por nodoEscalabilidadNo Moderada Si VariaApertura Cerrado Cerrado Abierto Abierto

Diseño de Sistemas Operativos - Tema 2 6Comunicación en DOSVisión de alto nivel:• El proceso llamador (cliente)se suspende.• Los parámetros delprocedimiento se pasan alproceso llamado (servidor).• El servidor ejecuta elprocedimiento, y devuelve losparámetros de retorno.• Se reanuda al llamador.Empaquetadode parámetrosClienteCallReturnTocónclienteKernelRPCruntimeRPCruntimeDesempaquetadode parámetrosTocónservidorCallReturnKernelRedServidor

Diseño de Sistemas Operativos - Tema 2 7RPC: paso de parámetros• Empaquetado de parámetros (marshaling) - el tocón clienteempaqueta los parámetros en un mensaje.• Desempaquetado de parámetros (unmarshaling) - el tocónservidor desempaqueta los parámetros para una llamada aprocedimiento local.• Manejo de diferentes representaciones de datos:– ASCII, EBCDIC; complemento a 1, a 2, punto flotante; big endiany little endian.• Se establece una forma canónica de representación dedatos , p. ej. XDR (eXtended Data Representation).

Diseño de Sistemas Operativos - Tema 2 8RPC: 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 losdatos) - se pasan parámetros en el mensaje.• No se pueden realizar llamadas por referencia (procedimientoobtiene un puntero a los datos). En su lugar, realiza llamada porcopia - en lugar de un puntero se pasa el item al que apunta, elprocedimiento lo modifica y lo devuelve. Se produciráninconsistencias si el cliente no se bloquea.

Diseño de Sistemas Operativos - Tema 2 9RPC: Generación de tocones• C/C++ no son lo suficientemente expresivos para generarlos tocones automáticamente:• no expresan qué parámetros son de entrada, de salida, dee/s; tamaño exacto de los parámetros; que significa pasarun puntero.• Necesitamos un lenguaje de definición de interfaces (IDL)para la especificación de las signaturas del procedimientopara poder generar los tocones.• Ventaja: Hay herramientas que compilan la especificación ygeneran los tocones, p. ej. rpcgen de Sun.

RPC: generación de tocones (ii)Diseño de Sistemas Operativos - Tema 2 10

Diseño de Sistemas Operativos - Tema 2 11RPC: autenticación• RPC utiliza 5 mecanismo de autentificación:– AUTH_NULL – sin autentificación– AUTH_UNIX – credenciales estilo Unix: nombremàquina cliente, UID y GID.– AUTH_SHORT – devuelta por el servidor tras unaAUTH_UNIX para posteriores peticiones.– AUTH_DES – autentificación segura utilizandoclaves privadas– AUTH_KERB – idem utilizando Kerberos.

Diseño de Sistemas Operativos - Tema 2 12ServidoresServidor con estado: mantieneinformación de estado de cada clientey archivo.• Orientado a la conexión (abrirarchivo, leer/escribir, cerrar)• Permite optimizaciones delservidor como lectura adelantaday bloqueo de archivos.• Es difícil recuperar el estadodespués de una caída.Servidor sin estado: no mantieneesa información• Cada solicitud es autocontenida(archivo, posición, acceso). Noorientado a conexión (abrir ycerrar están implicadas).• Si el servidor cae, los clientessimplemente repiten lassolicitudes hasta que se recupere.• No optimizaciones del servidor.• Ciertas operaciones idempotentes.

Diseño de Sistemas Operativos - Tema 2 13Ligadura• La ligadura es la operación para determinar elservidor y el procedimiento remoto a llamar.• Ligadura en compilación - la dirección delservidor(es) está empotrada en el código . Esinflexible si el servidor cambia de ubicación, oexisten múltiples copias de un servidor.• Ligadura en tiempo de enlace - el cliente solicitaun handle antes de utilizar el servicio.• Ligadura en tiempo de llamada - el cliente seliga al servidor en la primera llamada.

Diseño de Sistemas Operativos - Tema 2 14Establecer la ligaduraDirección delservidor o handleal servidorServidor dedirectoriosBinder/trader/brokerRegistrode servicioClienteMáquinacliente24create3Handlecliente# puertoPortMapper1ServidorMáquina servidorRegistraprograma,versióny puerto

Diseño de Sistemas Operativos - Tema 2 15Ejemplo: NFS• Network File System (NFS) – Sistema dearchivos que permite a un usuario almacenar susarchivos en máquinas de una red.• Un servidor NFS exporta sistemas de archivos asus clientes. Un cliente NFS monta sistemas dearchivos remotos como si fuesen locales.• Ambos utilizan el protocolo NFS construido sobreRPC.

Diseño de Sistemas Operativos - Tema 2 16FS locales y remotosServer 1(root)Client Server 2(root)(root)export. . . vmunix usrnfspeopleRemotemountstudentsxstaffRemotemountusersbigjonbob. . .jimannjane joe

Diseño de Sistemas Operativos - Tema 2 17NFS Versión 4: requisitos• Acceso mejorado y buen rendimientosobre Internet.• Seguridad fuerte, con negociación de laseguridad construida en el protocolo.• Interoperatividad mejoradad entreplataformas cruzadas.• Extensibilidad del protocolo.

Diseño de Sistemas Operativos - Tema 2 18NFS v.4: características• Nuevas características de NFS v.4 (RFC 3530):– Estado de seguimiento de archivos (bloqueo, lecturay 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

Diseño de Sistemas Operativos - Tema 2 19NFS: reducción del tráfico• Dos mecanismos:– RPC compuesta (compound): permite múltiples llamadasRPC embebidas en una misma petición.– Garantía de la consistencia de las cachés de los clientesmediante las operaciones de delegación sobre archivosregulares. Similar al bloqueo de archivos (diferencias: sedelega en un cliente, no en procesos particulares; elbloqueo es solicitado por los clientes; la delegación puedeser reclamada por el servidor en cualquier instante)

Diseño de Sistemas Operativos - Tema 2 20NFSv4: servidor con estado• A diferencia de las versiones anteriores, NFSv4es un servidor con estado:– Las operaciones de bloqueo de archivos son partedel protocolo NFS, eliminando la necesidad de losdemonios rpc.statd y rpc.lockd.• El estado esta basado en arrendamiento (leasebased):este expira si el cliente no realizaoperaciones que manipulan el estado dentro delservidor durante el periodo de usufructo. Uncliente puede renovar el estado con RENEW.

Diseño de Sistemas Operativos - Tema 2 21Estado 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 enbase 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 serabierto como máximo una vez por cada lockowner.– Identificador del estado (stateid): cada stateid identifica unarchivo abierto (parecido a un descriptor de archivo) y esnecesario para las operaciones de manipulación del archivo.

Diseño de Sistemas Operativos - Tema 2 22RPC compuesta• Esta RPC subsume todas las operaciones previasexcepto el procedimiento NULL.• Su procesamiento no es atómico, se serializa, y paraen la primera operación que de error.• Implicación: no podemos implementar la cache derespuesta en el dispatcher rpc. La capa RPC no saberque procedimiento se esta procesando (solo hay 1),por lo que el procesamiento descansa en la capa XDR.

Diseño de Sistemas Operativos - Tema 2 23NFS v4: Delegación• Cuando un cliente abre un archivo, el servidor retorna alcliente:– Delegación de lectura: garantía de que ningún otro cliente haabierto el archivo de escritura, por lo que el cliente puede cachearlos datos sin necesidad de chequeos de consistencia.– Delegación de escritura: garantía de que ningún otro cliente haabierto el archivo de ninguna forma, por lo que es libre de diferir oagrupar las escrituras en el servidor.• Un cliente no puede ni solicitar ni rehusar delegaciones,pero puede retornar una delegación a su elección.

NFS: ArquitecturaDiseño de Sistemas Operativos - Tema 2 25

Diseño de Sistemas Operativos - Tema 2 26NFS: uso• Servidor:– En /etc/exports añadir los directorios aexportar 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,hardserver:/ /mount/point

Diseño de Sistemas Operativos - Tema 2 27Enlaces• 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

Diseño de Sistemas Operativos - Tema 2 28Referencias• W. A. Adamon, y K.M. Smith, “Linux NFS Versión 4:Implementation and Administration”, Proceeding of the2001 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 2 nd SANE (System Administration andNetwork Engineering) Conference, May 22-25, Maastricht,The Netherlands 2000.

Diseño de Sistemas Operativos - Tema 2 29Innovaciones en NFS• PNFS (parallel NFS) –FS de escalado yrendimiento altos.• pNFS separa la capade datos de lospropios datos,permitiendo unaarquitectura decamino-dual.

Diseño de Sistemas Operativos - Tema 2 30Alternativas a NFS• En sistemas Windows: CIFS (CommonInternet File System) o también conocidocomo SMB (Server Message Block).• En Linux, Ceph: sistema de archivosdistribuido tolerante a fallos de altorendimiento y escalabilidad.

Diseño de Sistemas Operativos - Tema 2 31Ceph: 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.

Diseño de Sistemas Operativos - Tema 2 32Ceph: componentes• Object Storage Devices (OSD): los discos son reemplazados condispositivos con CPU, interfaz de red, caché local y disco o RAID. Separalas funciones de datos y metadatos eliminando las tablas de asignaciónde 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 operacionesde metadatos (open, rename, etc.), mientras que se comunicadirectamente con OSD para las operaciones de E/S (read, write).

Diseño de Sistemas Operativos - Tema 2 33Ceph: arquitectura• Fuse (Filesystem in UserSpacE) – sistema de archivosque permite al usuario crear sistemas de archivos virtualessin modificar el núcleo

Diseño de Sistemas Operativos - Tema 2 34Ceph: Dynamic SubtreePartitioning• Este mecanismo distribuye de formainteligente y adaptativa la responsabilidadde manejar la jerarquía de directoriosentre decenas/cientos de MDS

Diseño de Sistemas Operativos - Tema 2 35Ceph: distribución de datos conCRUSH• CRUSH (Controlled Replication Under Scalable Hashing)- Función dedistribución de datos seudo-aleatoria que mapea eficientemente cadaPG (Placement Group) en una lista ordenada de OSD sobre los quealmacenar replicas de objetos.

Diseño de Sistemas Operativos - Tema 2 36Ceph: enlaces y referencias• http://ceph.sourceforge.net• S.A. Weil, et al., “Ceph: A Scalable, High-Performance Distributed File System”,Proceeding of the 7 th USENIX Symposiumon Operating Systems Design andImplementation (OSDI'06), pgs. 307-320,2006.

Diseño de Sistemas Operativos - Tema 2 37Otros servicios distribuidos• Namespaces en Linux permite construirmecanismos ACR (Application Checkpointand Restart) sobre los que desarrollarsistemas de migración de computación.• Algunos ejemplos:– Zap– OpenVZ– VServer– MCR

Diseño de Sistemas Operativos - Tema 2 38Diferentes necesidades,sistemas diferentes• Sistemas Operativos de Internet (Cloudcomputing): 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)

Computación penetrante o ubícua*Comunicaciones remotascapas de protocolos, RPC, args end-to-end,..Tolerancia a fallosACID, transacciones anidadadas, ...Alta disponibilidadReplicación, recuperación rollbackAcceso a información remotaSists, archivos distribuidos, BDs, cachesSeguridad distribuidaEncriptación, autenticación mutua, ...SistemasDistribuidosRedes móvilesIP mobiles, redes ad hoc, TCP wireless, ...Acceso a la información móvilOperaciones desconectadas, consistencia débil, ...Aplicaciones adaptativasTranscoding proxies, gestión adaptativa de recursos, ...Sistemas “energy-aware”Adaptación dirigida por objetivos, discos con parada, ...Sensibilidad de ubicaciónGPS, conciencia del contexto, ...ComputaciónmóvilComputaciónpenetranteEspacios inteligentesEmpotrar computación enconstrucciónInvisibilidadDistracción mínina del usuarioEscalabilidad localizadaReducir interacciones con ladistanciaAcondicionado irregularReducir las variaciones vistas porel usuario* Extraido de [Sataylayout2001]Diseño de Sistemas Operativos - Tema 2 39

Diseño de Sistemas Operativos - Tema 2 40Cloud Computing• “Modelo que permite un acceso conveniente y bajo demanda de red auna bolsa de recursos de computación configurables (redes, servidores,almacenamiento, aplicaciones y servicios) que pueden suministrase deforma rápida y liberarse con un mínimo esfuerzo de mantenimiento ointeracción con el suministrador de servicios” [National Institute ofStandards and Technology].• No es una nueva tecnología, sino un nuevo modelo de operación detecnologías existentes.

Diseño de Sistemas Operativos - Tema 2 41Arquitectura cloud-computingSaaS = suministraaplicaciones bajo demandasobre InternetPaaS = suministra recursosde plataforma, incluidosoporte de SO y frameworkde desarrollo softwareIaaS = suministra recursos deinfraestructura bajo demanda,usualmente en términos deVM.Extraida de Qi Zhang, Lu Cheng y Raouf Boutaba, “Cloud computing: stateof-the-artand research challenges”, Internet Services and Applications, Vol.1, No. 1, pp. 7-18, May 2010.

Diseño de Sistemas Operativos - Tema 2 42Cloud Operating Systems• Cloud SO = tipo de SO diseñado paraoperar en entornos de computación ennube y virtualizados, que gestiona lasoperaciones, ejecución y procesos de lasmáquinas virtuales, servidores virtuales einfraestructura virtual, además dehardware del servidor y los recursossoftware.• También se puede denominar comosistemas operativo virtual, sistemaoperativo de internet, webOS.• El SO de la nube gestiona diferentesservidores y dispositivos hardware, dandola impresión a los usuarios de que estáninteraccionando con una nube de infinitacapacidad y elasticidad.

Diseño de Sistemas Operativos - Tema 2 43Modelo lógico de un Cloud OSExtraída de F. Pianes et al., “Toward a Cloud Operating System”, NetworkOperations and Management Symposium Workshops (NOMS Wksps), pages335-342, IEEE/IFIP, 19-23 April, 2010.

Diseño de Sistemas Operativos - Tema 2 44Elementos del modelo• Objeto nube (CO)= conjunto de procesos locales que se ejecutan en un único nodo, que estanepaquetados 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, ymedida de los recursos.• Aplicaciones de usuario = CPs ejecutadas directamente por el usuario que interacciona con lasbibliotecas 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 elgestor de procesos y la gestión de MV y la información resultante se hace disponible a la nube víala biblioteca de naming. La biblioteca de nombres mantiene también la relación entre los CPs de laaplicació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.

Diseño de Sistemas Operativos - Tema 2 45Sistemas Operativos para lanube• Sistemas operativos actuales:– Cloud Operating Systems:• VMware vSphere 4• Ubuntu Enterprise OS– Web-Based Cloud Operating Systems:• iCloud• eyeOS• Glide OS• g.ho.st

Diseño de Sistemas Operativos - Tema 2 46Sistemas 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 componentesdenominados servicios Web.• Cambio de modelo de aplicación: el modelo IOS permite combinar lafacilidad de uso y mantenimiento de una aplicación web con las ventajas deintegración disponible en aplicaciones nativas.• Difumina la interfaz del SO

Diseño de Sistemas Operativos - Tema 2 47Componentes de un IOS• Vamos a comparar los componentestradicionales de un SO y computador con loscomponentes del IOS:– CPU– Sistema de archivos– Jerarquía de memoria– Mensajes– Directorios– Seguridad– . . .

Diseño de Sistemas Operativos - Tema 2 48IOS: CPU• Internet puede verse como un multiprocesadordistribuido y másivamente paralelo.• Tenemos dos extremos:– Computación Grid – una tarea puede descomponerse elmúltiples hebras y ejecutarse en paralelo en múltiplescomputadores de la red. Por ejemplo, WebOS, Legion,GoogleOS, etc.– Sistemas peer-to-peer – donde existe poca o nulacoordinación entre los nodos. Por ejemplo, Napster,Gnutella, SETI@Home, etc.

Diseño de Sistemas Operativos - Tema 2 49IOS: Almacenaje de archivos• El sistema de archivos de Internet consta de losdispositivos de almacenamiento de numerososcomputadores conectados a la red.• Podemos tener particiones del disco gestionadas poraplicaciones distribuidas.• Ejemplo, devfs2 es un manejador de disco de Linuxque soporta el sistema de archivos WebDAV (estándarXML define cómo se gestionan los archivos y carpetasen Internet y en las plataformas J2EE y .NET)

Diseño de Sistemas Operativos - Tema 2 50IOS: Jerarquía de memoria• Actualmente, el único elemento similar a una jerarquía dememoria es la caché del navegador web.• Esta caché es pequeña comparada con la cantidad deinformación a almacenar -> muchas faltas de cache -> esnecesario, 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 áreaen desarrollo.

Diseño de Sistemas Operativos - Tema 2 51IOS: Mensajería• La composición de servicios basados enWEB para construir aplicaciones deInternet debe basarse en mecanismo decomunicación estándares como HTTP,XML, y SOAP, para que esoscomponentes puedan intercambiar datos yservicios de forma fácil.

Diseño de Sistemas Operativos - Tema 2 52IOS: Directorios• Una aplicación basada en web debe sercapaz de localizar dos tipos de recursosdistribuidos: 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 unestándar para este tipo de directorio.

Diseño de Sistemas Operativos - Tema 2 53IOS: Seguridad• Requiere la misma lista de servicios deseguridad que los SOs de servidores, ladiferencia es la escala: gestión de perfilesde usuarios, autenticación, autorización,comunicaciones seguras, única firma paravarias aplicaciones.• Por ejemplo, Microsoft Passport es unmecanismo de firma única paraaplicaciones del portal MSN.

Diseño de Sistemas Operativos - Tema 2 54Ejemplo:• Esta basado en un kernel 2.6 de Linux, conuna combinación componentes Palm quesuministran servicios a nivel de usuario(CoreOS: kernel de Linux, manejadores,servicios del SO, Middleware, wireless, ysubsistema de medios).• El usuario no interacciona con CoreOS sinocon el Entorno de Aplicación (aplicaciones yUI System Manager)

Diseño de Sistemas Operativos - Tema 2 55Arquitectura de Palm webOSAPI de WebOS(FrameworkJavaScript)Core OSFigura extraída de M. Allen, Palm webOS, O'Reilly, 2009

Diseño de Sistemas Operativos - Tema 2 56Sistemas Operativos en Cluster• Grid computing = paradigma de computacióndistribuida que coordina recursos en red paraalcanzar un objetivo computacional común.• Diferencia con Cloud computing: ésta utilizatecnologías de virtualización a múltiples niveles(hardware y plataforma de aplicación) paracompartir y suministrar recursos de formadinámica.• Podemos diferenciar un cluster de un sistemagrid, en que el primero es un sistema limitadoen una red limitada.• Un cluster permite:– Equilibrio de carga– Compensación de fallos– Procesamiento paralelo

Diseño de Sistemas Operativos - Tema 2 57Planificación distribuida• Un Linux estándar no tiene soporte para planificacióndistribuida (si para SMP, SMT y MC).• Algunas soluciones:– Beowulf Job Manager (BJM) – Job= colección de PIDsejecutándose en un nodo propiedad del mismo usuario. Cadausuario tiene una única cola de trabajos (permite controlar cuantasCPUs 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 contextousuario (problemas con E/S).– Maui Scheduler – planificador batch para HPC. Permite reservade nodos a grupos o usuarios.

Diseño de Sistemas Operativos - Tema 2 58Procesadores multi-core• Múltiples procesadoresindependientes en unmismo IC quecomparten algunoselementos (p. ej. cacheL2, bus, ..)• Los núcleos puedenser homogéneos oheterogéneos.

Diseño de Sistemas Operativos - Tema 2 59Soporte del SO a CMP• Los SOs actuales tratan estos sistemascomo multiprocesadores clásicos• Problema: no se explotan al máximo lascapacidades del sistema• Los problemas se agravan en sistemasheterogéneos, donde el SO no los soportatotalmente de forma nativa, es decir, lasaplicaciones deben gestionar directamentelos núcleos.

Diseño de Sistemas Operativos - Tema 2 60Planificación de CMP• Principal reto: identificar y predecir los recursosnecesitados por cada tarea y planificar las tareas paraminimizar la contención de los recursos compartidos,máximizar la utilización de recursos, y explotar lasventajas de los recursos compartidos entre losnú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

Diseño de Sistemas Operativos - Tema 2 61Planificación enmultiprocesadores• El kernel 2.6 de Linux soporta planificación en sistemasSMT, SMP y NUMA• Introduce el concepto de dominios de planificación queincorpora información de la topología en el planificador.• Un dominio de planificación contiene una lista de grupos deplanificación que tienen propiedades comunes.• En cada nivel de dominio se ejecuta un equilibrador decarga. Las propiedades del dominio dictan el equilibradoentre grupos de planificación en ese dominio.

Diseño de Sistemas Operativos - Tema 2 62Dominios de planificación• Sistema NUMA con procesadores SMT: 3dominios de planificación-Proximidadde memoria+

Diseño de Sistemas Operativos - Tema 2 63Implementación• Los parámetros deplanificación sealmacenan en lasestructurassched_domain ysched_group

Diseño de Sistemas Operativos - Tema 2 64Implementación (ii)• El planificador intenta mantener la carga del sistema lo másequilibrada posible, ejecutando el re-equilibrado cuando se producenciertos 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 procesosacotados por CPU consuman todos los ciclos de un procesador.

Diseño de Sistemas Operativos - Tema 2 65Equilibrio de carga• iter_move_one_task – coge una tarea de la cola deejecución (rq) más ocupada y la encola en la CPU actual.• load_balance – permite distribuir múltiples tareasdesde la rq más ocupada a la CPU actual, pero no másde la especificada en max_load_move.• Activación

Diseño de Sistemas Operativos - Tema 2 66Gestión de potencia• Un aspecto importante a considerar en los diseñoactuales es la gestión de potencia, encaminada amantener 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 ycpupower) y planificación

Diseño de Sistemas Operativos - Tema 2 67Especificación ACPI• Advanced Configuration and PowerInterface: especificación abierta para lagestión de potencia y gestión térmicacontroladas 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 mecanicoTecharp, PC Power Management Guide Rev. 2.0,disponible enhttp://www.techarp.com/showarticle.aspx?artno=420

Diseño de Sistemas Operativos - Tema 2 68Estados de la CPU• S-estados: estados dormidosen G1. Van de S1 a S5.• C-estados: estados depotencia en G0. C0:activo,C1:halt, C2:stop, C3, deepsleep,...• P-estados: relacionados conel control de la frecuencia y elvoltaje del procesador. Seusan con G0 y C0. P1-Pn, amayor 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

Diseño de Sistemas Operativos - Tema 2 69Infraestrucutra CPUfreq• El subsistema CPUfreq es el responsable de ajustarexplícitamente la frecuencia del procesador.• Estructura modularizada que separa políticas (gobernadores) demecanismos (drivers específicos de CPUs).Gobernadoresa nivel usuarioGobernadoresen el kernelPerformancePowersaved cpuspeedConservativePowersave Userspace OndemandMódulo CPUfreq (interfaces /proc y /sys)Drivers específicosDe CPUacpi-cpufreqspeedstep-centrinoPowernow-k8Driver ACPI del procesador

Diseño de Sistemas Operativos - Tema 2 70Gobernadores• Performace – mantiene la CPU a la máxima frecuenciaposible dentro un rango especificado por el usuario.• Powersave – mantiene la CPU a la menor frecuencia posibledentro del rango.• Userspace – exporta la información disponible de frecuenciaa nivel de usuario (sysfs) permitiendo su control al mismo.• On-demand – ajusta la frecuencia dependiendo del usoactual 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

Diseño de Sistemas Operativos - Tema 2 71Herramientas• Cpufrequtils – podemos ver, modificar los ajustes del kernel relativos alsubsistema CPUfreq. Las órdenes cpufreq* son utiles para modificar losestados-P, especialmente escalado de frecuencia y gobernadores.• Cpupower – ver todos los parámetros relativos a potencia de todas lasCPUs, incluidos los estados-turbo. Engloba a la anterior.• PowerTOP – ayuda a identificar las razones de un consumo altoinnecesario, por ejemplo, procesos que despiertan al procesador delestado ocioso.• Se pueden crear perfiles en /etc/pm-profiler.

Diseño de Sistemas Operativos - Tema 2 72Planificación y energía• En CMP con recursos compartidos entre núcleos de unpaquete físico, el rendimiento máximo se obtiene cuando elplanificador distribuye la carga equitativamente entre todos lopaquetes.• En CMP sin recursos compartidos entre núcleos de unmismo paquete físico, se ahorrará energía sin afectar alrendimiento si el planificador distribuye primero la carga entrenúcleos de un paquete, antes de buscar paquetes vacíos.

Diseño de Sistemas Operativos - Tema 2 73Algoritmos de planificación• El administrador elige la política de planificación: entradassched_mc_power_saving y sched_smt_power_saving de/sys/devices/system/cpu/. Esto básicamente desactiva elequilibrado de carga (ajuste estados-C).Rendimiento óptimoAhorro de energía• A partir del kernel 3.4, esta solución ha desaparecido y seestán buscando otras alternativas.

Diseño de Sistemas Operativos - Tema 2 74Bibliografía• HP, Intel, Microsoft, Phoenix, y Toshiba, “Advanced Congiguration andPower Interface Specification Rev. 5.0”, Dic. 2011, disponible enhttp://www.acpi.info/DOWNLOADS/ACPIspec50.pdf• Jenifer Hopper, IBM developerWork, 2009, “Reduce Linux powerconsumpsion:– 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 enhttp://doc.opensuse.org/documentation/html/openSUSE/opensusetuning/cha.tuning.power.html.

Diseño de Sistemas Operativos - Tema 2 75Planificación: grupos de control• El planificador trata con entidades planificables: tareaso grupos de tareas.• Esto permite definir grupos de planificación – Diferentesprocesos se asignan a diferentes grupos. El planificadorreparte la CPU imparcialmente entre grupos, y luegoentre proceso de un grupo. Esto reparte imparcialmentela CPU entre usuarios.

Diseño de Sistemas Operativos - Tema 2 76Grupos de control• Suministran un mecanismo para:– Asignar/limitar/priorizar recursos: CPU, memoria, ydispositivos.– Contabilidad: medir el uso de recursos.– Aislamiento: espacios de nombres separados porgrupo.– Control: congelar grupos o hacer checkpoint/restart.• Los cgroups son jerárquicos: un grupo heredalos límites del grupo padre.

Diseño de Sistemas Operativos - Tema 2 77Subsistemas de grupos decontrol• 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 dememoria 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 detráfico (tc) identificar los paquetes originados en una tarea de un grupo.– Ns: subsistemas de espacios de nombres (namespaces), visto en Tema 1,

Diseño de Sistemas Operativos - Tema 2 78Relaciones entre subsistemas,jerarquias, cgroups y tareas• Definiciones:– Tarea: proceso de usuario o kernel– Cgroup: una o más tareas.– Subsistema: modulo que modifica elcomportamiento de las tareas de un cgroup.– Jerarquía: varios cgroups en un árbol.• Existen 4 reglas que gobiernan la relaciónentre subsistemas, jerarquías, grupos decontrol y tareas (procesos):

Diseño de Sistemas Operativos - Tema 2 79Regla 1: una única jerarquía puede tener uno o variossubsistemas ligados a ellaSubsistema CPUSubsistema Memoria/cpu_mem_cg/cg_1/cg_2Jerarquía cgroup

Diseño de Sistemas Operativos - Tema 2 80Regla 2: Un subsistema ligado a una jerarquía A nopuede ligarse a otra jerarquía B, si la B tiene un subsistemadiferente ligado a ellaSubsistema CPU/cpu_cgSubsistema Memoria/cpu_mem_cg/cg_1/cg_3/cg_2/cg_4Jerarquía cgroup AJerarquía cgroup B

Diseño de Sistemas Operativos - Tema 2 81Regla 3: una tarea no puede ser miembro de dos cgroupsdiferentes en la misma jerarquíaSubsistema CPUSubsistema MemoriaSubsistemanet_cls/cpu_cg/cg_1tareasHttpd4563/net/cg_3/cg_2tareasJerarquía cgroup AtareasJerarquía cgroup B

Diseño de Sistemas Operativos - Tema 2 82Regla 4: Una tarea hereda los mismos cgroups que supadreSubsistema CPUSubsistema Memoria/cpu_cg/cg_1 tareasJerarquía cgroupHttpd4563Httpd4570fork()

Diseño de Sistemas Operativos - Tema 2 83Uso de Grupos de control• Pueden utilizarse de diferentes modos:– Seudo-sistema de archivos cgroups (cgroupfs).– Herramientas de libcgroup: cgcreate, cgexec,cgclassify, ...– El demonio engine rules los gestiona según lainformación de los archivos de configuración.– Indirectamente a través de otros mecanismoscomo Linux Containers (LXC), libvirt, systemd.

Diseño de Sistemas Operativos - Tema 2 84Método 1: Cgroups File System• Los subsistemas se habilitan como una opción de montaje de cgroupfs:mount -t cgroup -o$subsistema• Habilitamos los archivos del subsistema en cada cgroup (directorio):/dev/cgroup/migrupo/subsysA.optionB• Podemos verlos en /proc/cgroups.• En Ubuntu, podemos instalarlo con$ sudo aptitude install cgroups-bin libcgroup1• Esto nos monta por defecto los siguientes fs:$ ls -l /sys/fs/cgroupcpu cpuacct devices memory• Podemos ver los grupos de control con cat /proc/cgroups

Diseño de Sistemas Operativos - Tema 2 85Cgroupsfs: ejemplo• Crear dos grupos para asignar tiempo de CPU:– Creamos el correspondiente subdirectorio en sys/fs/cgroup/cpu:$ mkdir navegadores; mkdir multimedia– Asignamos el porcentaje de cpu al grupo escribiendo en el archivocpu.shares:$ echo 1024 > /sys/fs/cgroup/cpu/navegadores/cpu.shares$ echo 2048 > /sys/fs/cgroup/cpu/multimedia/cpu.shares– Movemos una tarea al cgrupo escribiendo su PID en el archivo tasks.$ firefox&$ echo $! > /sys/fs/cgroup/cpu/navegadores/tasks$ mplayer micancion.mp3&$ echo $! > /sys/fs/cgroup/cpu/multimedia/tasks

Diseño de Sistemas Operativos - Tema 2 86Método 2: Servicio cgconfig• El servicio cgconfig se instala conlibcgroup.• Este servicio lee la información de/etc/cgconfig.conf, lo que permite hacerasignaciones entre sesiones, por tanto,hace la configuración permanente.• Podemos arrancarlo/pararlo/reiniciarlo con$ service cgconfig [start | stop | restart]

Diseño de Sistemas Operativos - Tema 2 87/etc/cgconfig.conf• Este archivo tiene las entradas:mount { /* crea y monta jerarquías como fs*/ = …}group { /*crea grupos y establece */[] /* parámetros de subsistema */ { = …}…}

Diseño de Sistemas Operativos - Tema 2 88/etc/cgconfig.conf (ii)• Donde tiene la estructura:perm {task {uid = ;gid = task group>;}admin {uid = ;gid = ;}}

Diseño de Sistemas Operativos - Tema 2 89Ejemplos• Crear jerarquía para cpuset:mount {cpuset = /cgroup/red;}• Crear cgrupo para demonios sql conpermisos usuarios de grupo sqladminpara añadir tareas al cgrupo y el rootpuede modificar parámetros:group daemons/sql {perm {task {uid = root;gid = sqladmin;} admin {uid = root;gid = root;}} cpu {cpu.shares = 100;}}• Equivalente en cgroupfs:# mkdir /cgroup/red# mount -t cgroup -o cpuset red/cgroup/red• Equivalente:# mkdir -p /cgroup/cpu/daemons/sql# chown root:root/cgroup/cpu/daemons/sql/*# chown root:sqladmin/cgroup/cpu/daemons/sql/tasks# echo 100 >/cgroup/cpu/daemons/sql/cpu.shares

Diseño de Sistemas Operativos - Tema 2 90Método 3• Al instalar libcgroup podemos usar:– cgcreate: crea un cgrupo.– cgdelete: borra un cgrupo.– cgset: estable los parámetros de un cgrupo.– cgclassify: mueve un proceso a un cgrupo.– cgexe: lanza un proceso en un cgrupo.– cgsnapshot: genera /etc/cgconfig.conf a partir de laconfiguración actual de los cgrupos.– lssubsys: muestra los subsistemas ligados a unajerarquía.

Diseño de Sistemas Operativos - Tema 2 91Método 4• El demonio cgred mueve tarea entre cgrupos de acuerdo con losparámetros establecidos en /etc/cgrules.conf.• Las entradas del archivo /etc/cgrules.conf puede tener dos formas:usuario jerarquías grupo_controlusuario:orden jerarquías grupo_control• Podemos usar la notación extra:– @ - indica un grupo de usuario.– * - representa a todos.– % - representa al item de la línea superior.• Ej.: Todo proceso del usuario maria accede al subsistema dispositivosde acuerdo a los parámetros especificados en /usergroup/staff:maria devices /usergroup/staff• Ej. 2: cuando maria usa ftp el proceso se mueve a /usergroup/staff/ftp:maria:ftp devices/usergroup/staff/ftp

Diseño de Sistemas Operativos - Tema 2 92Bibliografia de cgroups• Documentación en/usr/src/linux/Documentation/cgroups• Prpič, M., Landman, R. y Silas, D., Red Hat EnterpriseLinux 6. Resource Management Guide, Red Hat Inc.,2011.• Henningsen, G., “How I Used Cgropus to ManageSystem Resources”, 1/30/2012, disponible en línea(24/4/12) enhttp://www.oracle.com/technetwork/articles/serversstorage-admin/resource-controllers-linux-1506602.html

Diseño de Sistemas Operativos - Tema 2 93Multi-core en sistemas detiempo-real y empotrados• El sistemas de tiempo-real con plazos estrictos,la planificación de tareas no es suficiente paraalcanzar predecibilidad. Los eventos y tareascríticas del sistema siguen introduciendo ciertaimpredecibilidad.• Para tratar este problema se recurre alparticionado del sistema.• Dos formas:– Particionado horizontal– Particionado vertical

Diseño de Sistemas Operativos - Tema 2 94Particionado horizontal• HAL virtualiza el hardware: atrapa ypropaga los eventos externos a losdominios.• Ejemplos: RTAI, VxWorks, PaRTiKle, etc.

Diseño de Sistemas Operativos - Tema 2 95Particionado vertical• Los recursos se asignan directamente alas tareas críticas.• Ejemplo, ASMP-Linux

Diseño de Sistemas Operativos - Tema 2 96ASMP-Linux• ASymetric MultiProcessor Linux es una extensión al kernelde Linux para sistemas multicore y multiprocesadores conrequisitos de tiempo-real (parche para el 2.6.19.1).• Un kernel asimétrico considera a los procesos de tiempo-realy a los dispositivos relacionados como privilegiados y losprotegen de otras actividades del sistema• Es un SO particionado verticalmente:– partición de sistema: ejecuta actividades no de tiempo-real,como demonios, ISR no críticas, procesos convencionales, etc.– particion(es) de tiempo-real: consta de un procesador (CPUprotegida) y nirq >=0 IRQ líneas asignadas a ese procesador, yntask>=0 tareas de tiempo-real

Particionado en ASMP-LinuxDiseño de Sistemas Operativos - Tema 2 97