Sistemas Operativos II MC. Daniel Fajardo Delgado INSTITUTO TECNOLÓGICO DE CD. GUZMÁN 20 de Marzo de 2004.

Slides:



Advertisements
Presentaciones similares
Capítulo I Gestión de E/S 1.- Gestión de E/S 2.- Hardware de E/S 3.- Software de E/S.
Advertisements

III - Gestión de memoria
Administración de memoria
UNIX COMP 240.
Sistema operativo Componentes de un sistema operativo
III - Gestión de memoria
I.T.E.S.R.C. Romina Tamez Andrea Martínez Ma. De Lourdes Solís
3.4.- Administración de Memoria Virtual.
Estructura de un Sistema Operativo
ESTRUCTURA DEL SISTEMA OPERATIVO
Subsistemas De un Sistema Operativo Celeste Domínguez Romo
Sistemas en estratos. Descripción: se organiza en una jerarquía de estratos, estando construido cada uno de ellos sobre el otro que tiene menor jerarquía.
Introducción a los Sistemas Operativos Memoria Virtual
Estructuras en Sistemas Operativos
Windows XP sp3.
Johanna Lizeth Rodríguez Lorena Fda. Chávarro Ramos
Arquitectura de Conjunto de Instrucciones (ISA)
Mejoras a las Máquinas Von Neumann
ESTRUCTURA DE LOS SISTEMAS OPERATIVOS
Direcciones físicas y direcciones virtuales (lógicas)
Arquitectura del Computador
HILOS Y COMUNICACIÓN ENTRE PROCESOS
Tema 10: Gestión de Memoria
Administración de memoria
2. ASYNCRONOUS TRANSFER MODE 2.1Características generales 2.2 Modelo de referencia del protocolo 2.3 Categorías de servicio ATM.
UNIDAD 3 Conceptos de Sistemas Operativos.
Administración de Memoria Memoria Virtual
Las personas se enfrentaron por primera vez con programas que eran demasiados grandes para caber en la memoria disponible. La solucion fue dividir el programa.
Tema 10.3: Asignación de Espacio No Contiguo. Tema 10.3: 2 Silberschatz, Galvin and Gagne ©2005 Fundamentos de los Computadores (ITT, Sist. Electr.),
Overview Sistemas Computacionales
SISTEMA OPERATIVO Un sistema operativo es un programa que actúa como intermediario entre el usuario y el hardware de un computador y su propósito es proporcionar.
(Organización y Manejo de Archivos)
Asignación de Espacio No Contiguo
Soporte HW para Administración de Memoria Cecilia Hernández
Hebras Cecilia Hernández. Qué es un proceso? Consiste Espacio de direccionamiento Código a ejecutar Datos estáticos y dinámicos Pila o stack CPU: PC,
LOS SISTEMAS OPERATIVOS
Introducción a los Sistemas Operativos
Capítulo 7 Gestión de memoria.
El núcleo o kernel.
Gestión de procesos Sistemas Operativos Edwin Morales
TEMA 10. SISTEMAS OPERATIVOS DISTRIBUIDOS
Estructuras en Sistemas Operativos DAISY KATERINE RODRÍGUEZ.
1 Descripción y control de procesos Capítulo 3. 2 Requerimientos de un SO relacionados con procesos Ejecutar concurrentemente múltiples procesos para.
COMPONENTES DEL SISTEMA OPERATIVO.
Memoria virtual.
Gestión de Memoria.
Introducción a los SOs.
Teoría de Sistemas Operativos Administración de Archivos.
Tema 8: Introducción a los SOs. Tema 8: 2 Silberschatz, Galvin and Gagne ©2005 Fundamentos de los Computadores (ITT, Sist. Electr.), Introducción.
Almacenamiento virtual de sitios web “HOSTS VIRTUALES”
Gestión de Memoria.
UNIDAD 3 C ONCEPTOS DE S ISTEMAS O PERATIVOS. El ordenador es un sistema programable formado por un conjunto de elementos hardware que necesitan instrucciones.
Sistemas de Archivos Sistemas Operativos.  Se debe proporcionar un almacenamiento secundario que respalda a la memoria principal  El Sistema de archivos.
Unidad 2 – Gestión de Procesos
File Transfer Protocol.
Estructura del Sistemas Operativos por su Estructura
SEGMENTACIÓN DE LA RED UNIVERSIDAD NACIONAL DE INGENIERÍA
Teoría de Sistemas Operativos Memoria Departamento de Electrónica 2º Semestre, 2003 Gabriel Astudillo Muñoz
INTERRUPCIONES – ABRAZO MORTAL
3.2.1 Administración de almacenamiento
Elementos y tipos de sistemas operativos
Estructuras en Sistemas Operativos DAISY KATERINE RODRÍGUEZ.
TIPOS DE SISTEMAS OPERATIVOS.  Que es un sistema operativo??  Es el encargado de brindar al usuario una forma amigable y sencilla de operar, interpretar,
Universidad Metropolitana Introducción a la Computación Universidad Metropolitana Introducción a la Computación Septiembre, 2007 Arquitectura Von Newman.
Gestión de Memoria – Parte 2
Administración de Memoria Conceptos Swapping Asignación Continua Paginación Segmentación Segmentación con Paginación.
ARCHIVO Es una colección de información o bien es una secuencia de bits, bytes, líneas o registros definida por su creador.
Katty Evangelina Hipólito Chi.   Aunque cada maquina tiene un lenguaje ensamblador distinto, el proceso de ensamblador tiene suficiente similitudes.
Estructura del sistema operativo
1/50 Ing. Gerardo Chávez Malpartida Administración de Memoria SISTEMAS OPERATIVOS.
Transcripción de la presentación:

Sistemas Operativos II MC. Daniel Fajardo Delgado INSTITUTO TECNOLÓGICO DE CD. GUZMÁN 20 de Marzo de 2004

REPASO DE CONCEPTOS ADMINISTRACIÓN DE MEMORIA

La parte del SO que se encarga de la memoria se llama administrador de la memoria. Su labor es la de: ● Llevar el control de qué partes de la memoria están en uso y cuáles no la están. ● Asignar memoria a procesos cuando la necesiten y retirárselas cuando terminen. ● Administrar el intercambio entre la memoria central y el disco cuando la memoria central no baste para contener todos los procesos.

MONOPROGRAMACIÓN SIN INTERCAMBIO NI PAGINACIÓN Consiste en tener un sólo proceso en memoria a la vez y en permitir que ese proceso use toda la memoria... para variar, MS- DOS. Programa de usuario SO en RAM Programa de usuario SO en ROM Manejadores de dispositivos en ROM Programa de usuario SO en RAM 0 0XFFF...

Supongase que un proceso invierte una fracción p de su tiempo en un estado de espera de E/S. Con n procesos en la memoria al mismo tiempo, la probabilidad de que los n procesos esperen la E/S (en cuyo caso la CPU estará ociosa) es. La utilización de la CPU es por tanto 1 –. La utilización de esta unidad como función de n se le llama grado de multiprogramación. MULTIPROGRAMACIÓN Y USO DE LA MEMORIA Existe multiprogramación para facilitar la programación de una aplicación dividiéndola en dos o más procesos. Asimismo, se proporciona servicio interactivo a varias personas en forma simultánea y se evita menos ociosidad por parte del procesador.

MULTIPROGRAMACIÓN CON PARTICIONES FIJAS Se está en claro que es útil tener más de un proceso en la memoria al mismo tiempo. La pregunta es: Cómo debe organizarse la memoria para lograr este objetivo? La manera más simple consiste en dividir la memoria en n particiones (posiblemente desiguales). Por ejemplo, esta partición puede ser efectuada en forma manual por el operador cuando el sistema inicie. Cuando llega un trabajo, éste se puede colocar en la lista de espera de entrada hasta que se tenga la menor participación lo suficientemente grande para contenerlo. Cualquier espacio que no utilice un trabajo en una partición se pierde (FIGURA A). Una alternativa consiste en conservar una sola lista de espera (FIGURA B), el trabajo más proximo al frente de la lista podría cargarse en la partición vacía y ejecutarse.

Partición 4 0 Partición 3 Partición 2 Partición 1 SO 100 k 200 k 400 k 700 k Listas de espera de entradas múltiples Partición 4 0 Partición 3 Partición 2 Partición 1 SO 100 k 200 k 400 k 700 k Listas de espera de entrada única FIGURA AFIGURA B

El sistema de particiones fijas establecidas por el operador en la mañana y no cambiadas de ahí en adelante, fue utilizado por OS/360 en las macrocomputadoras de IBM por muchos años. Se le llamaba MFT (Multiprogramación con un número Fijo de Tareas, o bien OS/MFT). La multiprogramación introduce 2 problemas esenciales que deben solucionarse: - Recolocación. Suponga que la primera instrucción es una llamada a un procedimiento ubicado en la dirección relativa 50 dentro del archivo binario producido por el enlazador. Si este programa se carga en la partición 1, esta instrucción saltará a la dirección absoluta 50, la cual esta dentro del SO !! - Protección. Un programa maligno siempre puede construir una nueva instrucción y pasar a ella. Es indeseable que los procesos lean y escriban en la memoria que pertenece a otros usuarios.

Una solución consiste en equipar a la máquina con 2 registros especiales de hardware, llamados registros de bloque y de límite. Cuando se programa un proceso, el registro base se carga con la dirección inicio de su partición y el registro límite se carga con la longitud de la partición. Toda dirección de la memoria tiene el contenido del registro base sumado a él antes de enviarse a memoria. Por lo tanto, si el registro de base es 100 K, una instrucción CALL 50 se convierte efectivamente en una instrucción 100 K + 50, sin que se modifique la instrucción misma. El hardware protege los registros base y de límite para evitar que los programas de los usuarios los modifiquen. La IBM PC utiliza una versión más débil, tiene registros de base (los registros del segmento) pero no de límite.

INTERCAMBIO (Swapping) En un sistema de lote, la organización de la memoria es particiones fija es simple y efectiva. Con el tiempo compartido, la situación es diferente: normalmente hay más usuarios que memoria para contener todos sus procesos, tal que es necesario guardar los procesos extra en un disco. Desde luego, para ejecutar estos procesos deben traerse éstos a la memoria central. El paso de los procesos de la memoria central a un disco y de regreso se llama intercambio (swapping).

MULTIPROGRAMACIÓN CON PARTICIONES VARIABLES Cuando se emplean particiones variables, el número y tamaño de los procesos varía en forma dinámica todo el día. La flexibilidad de no atarse a un número fijo de particiones que puede ser demasiado grande o demasiado pequeño mejora la utilización de la memoria, mas también complica la asignación y desasignación de la memoria, así como su control. Qué cantidad de memoria debe asignarse a un proceso cuando éste se crea o se intercambia?

SO A A B A B C B C B C D C D C D E TIEMPO La asignación de la memoria cambia a medida que los procesos entran en la memoria y salen de ella. Las regiones de color marrón son memoria no usada.

Hace muchos años las personas se enfrentaron por vez primera a programas que eran demasiado grandes para caber en memoria disponible. La solución que soló adoptarse consistía en dividir el programa en partes, llamadas superposiciones. El trabajo real de intercambio de superposiciones era efectuado por el sistema, el trabajo de la división del programa en partes tenía que ser realizado por el programador. La división de programas grandes en pequeñas partes modulares consumía tiempo y era tedioso. Mejorando lo anterior surgió la memoria virtual. La idea básica es que el tamaño del programa, los datos y la pila combinados pueden exceder la cantidad de memoria física para él. El SO guarda aquellas partes del programas que se encuentran en uso corriente en la memoria central y el resto del disco. MEMORIA VIRTUAL

PAGINACIÓN La mayoría de los sistemas de memoria virtual emplean paginación. Cuando un programa utiliza una instrucción como MOV REG, 1000, éste desplaza el contenido de la dirección de memoria 1000 a REG. Las direcciones se pueden generar mediante el uso de indización, registros de base, registros de segmento y otras maneras. Estas direcciones generadas por el programa se llaman direcciones virtuales y forman el espacio de dirección virtual. Cuando se usa memoria virtual, las direcciones virtuales no pasan directamente al bus de memoria. En su lugar se dirigen a una unidad de administración de la memoria (MMU), que es un chip o conjuntos de chips que delinea direcciones virtuales en las direcciones de memoria física.

Memoria Controlador del disco Bus Tarjeta de CPU Unidad de administración de la memoria La MMU envía direcciones físicas a la memoria La CPU envía direcciones virtuales a la MMU

El espacio de direcciones virtual se divide en unidades llamadas páginas. Las unidades correspondientes en la memoría física se denominan cuadros de página. Las páginas y los cuadros de página siempre son del mismo tamaño. En este ejemplo tienen 4k, pero por lo común también e utilizan tamaños de 512 bytes, 1K, y 2 K. Las transferencias entre la memoria y el disco siempre están en unidades de una página. Por ejemplo, se tiene una computadora que puede generar direcciones de 16 bits, desde 0 hasta 64 K. Estas son direcciones virtuales. Sin embargo, esta computadora solo tiene 32 K de memoria física, de manera que aunque puedan escribirse programas de 64 K, no pueden cargarse en memoria en su totalidad y ejecutarse. No obstante, debe estar presente una copia completa de la imágen del núcleo de un programa, hasta de 64 K, en el disco, de manera que las partes se pueden traer al sistema conforme se necesiten.

X X X 5 X 7 X X X X 0-4K 4-8K 8-12K 12-16K 16-20K 20-24K 24-28K 28-32K 32-36K 36-40K 40-44K 44-48K 48-52K 52-56K 56-60K 60-64K 0-4K 4-8K 8-12K 12-16K 16-20K 20-24K 24-28K 28-32K Espacio de dirección virtual Direcciones de la memoria física Página virtual Cuadro de la página

Qué sucede si el programa intenta utilizar una página no delineada? La MMU advierte que la página no está delineada (cuadros con cruz) y hace que la CPU atrape al SO. Esta trampa se llama falla de página. El SO toma un cuadro de página con poco uso y vuelve a escribir su contenido a disco. Después captura la página recien referida en el cuadro de la página que acaba de liberarse, cambia el mapa y reinicia la ejecución capturada.

SEGMENTACIÓN Para algunas aplicaciones, conviene más de un espacio de dirección de diferentes tamaños. Los primeros segmentos de 64K podrían reservarse para procedimientos, datos, pilas y grupos, que pertenezcan al programa en ejecución. A diferencia de la paginación, donde por lo general el programador no tiene conocimiento de los límites de la página, con la segmentación el programador (o el compilador) hizo un intento definitivo por colocar diferentes objetos en segmentos distintos. Esta estrategia facilitó la compartición de objetos entre múltiples procesos.

On Microkernel Construction Jochen Liedtke

Desde un punto de vista de la tecnología del software, el concepto de microkernel es superior a los grandes kernels integrados. Por otro lado, se cree ampliamente que: (a) los sistemas basados en microkernel son inherentemente ineficientes y (b) no son lo suficientemente flexibles. Contradictoriamente a esta creencia, en el artículo se demuestra y soporta mediante evidencia documentaria que la ineficiencia e inflexibilidad de los actuales microkernels no está inherida a la idea básica, sino por el overloading del microkernel y/o por implementaciones inadecuadas.

Los sistemas basados en microkernel han sido construidos antes de que el mismo término fuera introducido por Brinch Ilansen [1970] y Wulf [1974]. Tradicionalmente, la palabra 'kernel' es utilizada para denotar la parte del SO que es mandatoria y común a todo el otro software. La idea básica del microkernel es minimizar esa parte implementando todo lo posible afuera del kernel. Las ventajas tecnológicas de este software son obvias: a) Una interface clara de microkernel que implementa una estructura del sistema más modular. b) Los servicios pueden usar los mecánismos provistos por el microkernel como cualquier otro programa de usuario. El mal funcionamiento del servidor es aislado así como cualquier otro mal funcionamiento de los programas de usuario. 1. FUNDAMENTO

c) Los sistemas son más flexibles y tolerables. Pueden existir en el sistema diferentes estrategias y APIs implementados por servicios diferentes. La mayoría de los microkernels existentes no se desempeñan lo suficientemente bien. La pérdida de eficiencia también restringe duramente la flexibilidad, donde mecanismos y principios importantes no pueden ser utilizados en la práctica a la par de un bajo rendimiento. En algunos casos, las interfaces de microkernel han sido debilitadas y servicios especiales han sido reintegrados dentro del kernel para retomar eficiencia. Los IPC (InterProcess Communication) convencionales, uno de los tradicionales cuellos de botella de los microkernels, pueden ser implementados con un orden de magnitud mayor, la pregunta está aún abierta. Puede ser posible de que aún no se estén aplicando las técnicas de construcción apropiadas.

2. ALGUNOS CONCEPTOS DE MICROKERNEL Se asume que el sistema destino tiene soporte interactivo y/o aplicaciones no completamente confiables. Tiene que tratar con protección. También se asume que el hardware implementa memoria virtual basada en páginas. Un requerimiento inevitable para tales sistemas es que un programador debe ser capaz de implementar un subsistema S absoluto, de tal manera que no puede ser perturbado o corrompido por otros susbsistemas S'. Este es el principio de independencia: S puede dar garantías de independencia de S'. El segundo requerimiento es que otros subsistemas deben ser capaz de basarse en esas garantias. Esto es, el principio de integridad: Debe haber un medio de hacia que establezca un canal de comunicación que no pueda ser corrompido ni escuchado por S'.

A nivel de hardware, un espacio de direcciones en un mapeo que asocia cada página virtual a un marco de página física (o lo marca como "no accesible"). Por simplicidad, se omiten atributos de acceso sólo-lectura y lectura/escritura. El mapeo es implementado por el hardware TLB y tablas de páginas. El TLB es un caché que guarda algunas entradas idénticas a las entradas de las tablas de páginas de la última tarea. El TLB es muy pequeño; en la simulación, tiene solamente cuatro entradas. También, hay solamente un TLB en la máquina. No hay un TLB para cada proceso. El microkernel, la capa mandatoria común a todos los subsistemas, tiene que ocultar el concepto de hardware de espacio de direcciones, de otra manera, la implementación de la protección sería imposible. 2.1 Espacio de direcciones

La idea básica es soportar la construcción recursiva del espacio de direcciones fuera del kernel. Por mágia, existe un espacio de dirección el cuál esencialmente representa la memoria física y está controlada por el primer subsistema En el tiempo de inicio del sistema, todos los otros espacios de memoria están vacíos. Para construir y mantener los espacios de direcciones sobre el tope de, el microkernel provee 3 operaciones: - Grant (donación). El propietario de un espacio de dirección puede donar cualquiera de sus páginas a otro espacio. La página donada es removida desde el espacio de dirección donador e incluida en el espacio de direcciones al que se donó. La restricción importante es que en vez de marcos de página físicos, el donador sólo puede donar páginas las cuales ya son accesibles a si mismas.

- Map. El propietario de un espacio de direcciones puede mapear cualquiera de sus páginas en otro espacio de direcciones. Después, la página puede ser accesada en ambos espacios de direcciones. En contraste a la donación, la página no es removida del espacio de direcciones mapeado. Comparado con el caso de donación, el mapeador puede solo mapear páginas que ya fueron accesadas. - Flush. El propietario de un espacio de dirección puede copiar y pasar cualquiera de sus páginas. La pagina pasada se mantiene accesible dentro del espacio de direcciones del flusher, pero es removida de todos los espacios de direcciones que han recibido la página directa o indirectamente del flusher. Los conceptos de espacio de direcciones descritos dejan la administración de memoria y paginación fuera del microkernel; sólo las operaciones grant, map y flush son retenidas dentro del kernel. Map y Flushing son requeridas para implementar administradores de memoria y paginadores en el tope del microkernel.

I/O Un espacio de direcciones es la abstracción natural para incorporar puertos de dispositivos. Esto es obvio para memoria mapeada a I/O. Pero los puertos de I/O también deben ser incluidos. Los derechos de control de I/O y controladores de dispositivos son también así hechos, mediante administradores de memoria y paginadores en el tope del microkernel.

2.2 Threads y IPC Un thread es una actividad ejecutandose dentro de un espacio de memoria. Un tread T es caracterizado por un conjunto de registros, incluyendo al menos un apuntador de instrucción, un apuntador de pila, y una información de estado. El estado del thread también incluye al espacio de direcciones en el cual T se ejecuta actualmente. Esta asociación dinámica o estática a los espacios de direcciones es la razón decisiva para incluir el concepto de thread dentro del microkernel. Para prevenir corrupción de espacios de direcciones, todos los cambios al espacio de direcciones del thread deben ser controlados por el kernel. En algunos SO, pueden haber razones adicionales para introducir threads como una abstracción básica, por ejemplo: preemption.

Por consecuencia, la comunicación entre espacios de direcciones, también llamadas Inter-Process Communication (IPC), debe ser soportada por el kernel. El método clásico es transferir mensajes entre threads por el microkernel. Otras formas de comunicación, las llamadas remotas a procedimientos (RPC) o la migración de threads controlados entre espacios de direcciones, pueden ser construidas desde la transferencia de mensajes basadas en IPC. Note que las operaciones grant y map necesitan IPC, ya que ellos requieren un acuerdo entre granter/mapper (donador/mapeador) y los recipientes del mapeo.

Interruptores La abstracción natural para las interrupciones del hardware son los mensajes IPC. El hardware es resguardado como un conjunto de threads los cuales tienen identificaciones (ids) y envían mensajes vacíos a threads de software asociados. Un thread receptor concluye de una fuente id de mensaje, donde el mensaje viene de una interrupción de hardware: driver thread: do wait for(msg,sender); if sender = my hardware interrupt then input/write io ports; reset hardware interrupt; else.... end_if end_do

3. FLEXIBILIDAD Para ilustrar la flexibilidad de los conceptos básicos, se esquematizan algunas aplicaciones las cuales normalmente pertenecen al SO básico, pero puede ser fácilmente implementadas en el tope del microkernel. Administrador de memoria. Un servicio manejando el espacio de direcciones inicial es un administrador clásico de memoria, pero fuera del microkernel. Los manejadores de memoria pueden facilmente ser apilados: mapea o dona partes de la memoria física a, controlado por, otras partes a, controlados por. Así se tienen 2 administradores de memoria coexistentes principales. Paginador. Un paginador puede ser integrado con un manejador de memoria o usar un servicio de manejador de memoria. Los paginadores utilizan las primitivas grant, map y flush del microkernel. Las interfaces restantes, servicios de paginación de memoria y paginadores, están completamente basados sobre IPC y están definidos como nivel de usuario.

Asignación de recursos multimedios. Los multimedios y otros recursos de tiempo real requieren recursos de memoria que sean asignados de una manera que mantenga el tiempo de ejecución predecible. Los manejadores de memoria y paginadores permiten por ejemplo, localidades fijas o memoria física para datos específicos o cierre de datos en memoria para un tiempo dado. Controlador de dispositivos. Proceso en el cual se accesa directamente a puertos de I/O de hardware mapeados dentro de su propio espacio de direcciones y mensajes recibidos desde el hardware (interrupciones) a través del mecánismo estándar de IPC. Comparados con otros procesos a nivel de usuario, no hay nada especial acerca de un controlador de dispositivo. Ningún controlador de dispositivo tiene que ser integrado dentro del microkernel. Caché de nivel secundario y TLB. Mejorando la tasa de aciertos de caché secundario mediante un método de asignación de páginas o reasignación, puede ser implementados por medio de un paginador que aplique alguna política de dependencia de cache (cache-dependent).

Comunicación remota. La IPC remota es implementada mediante los servicios de comunicación los cuales traducen los mensajes locales a protocolos de comunicación externa y viceversa. La comunicación del hardware es accesada mediante controladores de dispositivos. El microkernel no es involucrado. Servidor Unix. Las llamadas al sistema de Unix están implementadas por IPC. El servicio Unix puede actuar como un paginador para sus clientes y también utilizar memoria compartida para la comunicación con sus clientes. El servicio Unix a sí mismo puede ser paginable o residente. Conclusión. Un conjunto pequeño de conceptos del microkernel dirigen la abstracción la cual enfatiza la flexibilidad, ellas se desempeñan lo bastante bien.

4. RENDIMIENTO, HECHOS & RUMORES 4.1 Overhead de conmutación Se cree ampliamente que la conmutación entre el kernel y el modo usuario, entre espacio de direcciones, y entre threads, es inherentemente costosas. Algunas medidas soportan estas creencias Conmutación kernel-Usuario Ousterhout [1990] midió los costos de ejecutar la llamada getpid al kernel. Donde la operación real de getpid consiste sólo de un par de lecturas y almacenamientos. Este método mide los costos básicos de una llamada al kernel. Él demostró que la mayoría de las máquinas necesitan entre microsegundos por cada getpid, uno requirió incluso 63 microsegundos. Corroborando estos resultados, aquí se midió 18 microsegundos por el microkernel de Mach que llama a get_self_thread. De hecho, el costo medido en la llamada del kernel es alto.

Para el análisis de los costos medidos, nuestro argumento está basado sobre un procesador 486 (50 Mhz). Se tomó un procesador x86 debido a que el modo de conmutación usuario- kernel son extremadamente costosos en estos procesadores, se utiliza una medida del mejor caso para discusión, 18 microsegundos para Mach sobre una 486/50. Los costos medidos por la llamada al kernel son 18 x 50 = 900 ciclos.. Conclusión. Comparado con la teoría mínima, la conmutación del modo kernel-usuario son costosas en algunos procesadores. Comparados con los kernels existentes, sin embargo, ellos pueden ser mejorados de 6 a 10 veces mediante una construcción apropiada del microkernel. La conmutación del modo kernel-usuario no es un problema conceptual serio pero si uno de implementación.

4.1.2 Conmutación de espacio de direcciones. Tradicionalmente también se considera la conmutación del espacio de direcciones como costosa. La mayoría de los procesadores modernos utilizan un caché primario físicamente indexado, el cuál no es afectado por la conmutación del espacio de direcciones. La conmutación de la tabla de página es inusualmente muy barata: de 1 a 10 ciclos. El costo real está determinado por la arquitectura TLB. Algunos procesadores (por ejemplo, Mips R4000) utiliza TLBs etiquetados, donde cada entrada no sólo contiene la dirección de la página virtual, sino también el id del espacio de direcciones. La conmutación del espacio de direcciones es así transparente a el TLB y costos de ciclos no adicionales.

La mayoría de los procesadores actuales (486, Pentium, PowerPC, y Alpha) incluyen TLB no etiquetados. Una conmutación de espacio de direcciones requiere así de un TLB flush. El costo real está determinado por las operaciones de lectura del TLB las cuales son requeridas para reestablecer que el trabajo actual se establezca luego. Conclusión. La conmutación del espacio de direcciones debidamente construida no es muy cara, menos de 50 ciclos sobre los procesadores modernos. Sobre un procesadore de 100 Mhz, el costo inherente de la conmutación del espacio de direcciones puede ser ignorado, apenas si se realizan 100,000 conmutaciones por segundo. Optimizaciones especiales como la ejecución de servidores dedicados en el espacio del kernel, son supérfluas. El contexto de conmutación costoso en algunos microkernels existentes es debido a la implementación y no causado por problemas inherentes al concepto.

4.1.3 Conmutación de Threads e IPC Ousterhout [1990] también midió el contexto de la conmutación entre algunos sistemas Unix, haciendo eco de un byte mediante un pipe entre 2 procesos. Otra vez normalizando a una máquina de 10 Mips, la mayoría de los resultados Todos los microkernels existentes son al menos 2 veces más rápidos. Todas las veces que de usuario a usuario cruzan el espacio de direcciones, ellos incluyen una llamada al sistema, copia de argumentos, pila y espacio de direcciones con costos de conmutación. Conclusión. IPC puede ser implementado lo suficientemente rápido para manejar también las interrupciones de hardware mediante este mecanismo.

4.2 Efectos de memoria Chen y Bershad [1993] compararon el comportamiento del sistema de memoria de Ultrix, un grande sistema monolítico Unix con el que el microkernel Mach fue complementado con un servidor Unix. Las medidas hechas aquí de la degradación de memoria sugieren que estas son causadas solamente por el alto consumo de caché del microkernel. En otras palabras: reducir drásticamente el trabajo del caché resolverá el problema. Conclusión. La hipótesis de que la arquitectura microkernel es inherentemente dirigida a la degradación de la memoria del sistema no esta sustancianda. Por el contrario, las medidas (entre comillas) soportan la hipótesis de que la construcción apropiada de microkernels automáticamente evitará la degradación del sistema medida para Mach.

5. NO PORTABILIDAD Los viejos microkernels fueron construidos independientes de la máquina. Este enfoque tiene fuertes ventajas: los programadores no necesitaban conocer cuántos procesadores estaban y los resultados podían ser portados a nuevas máquinas. Desafortunadamente, este enfoque afecta el desempeño y flexibilidad. No debe sorprender de que la construcción de un microkernel asbtracto al hardware tiene implicaciones serias: – El microkernel no puede tomar ventajas del hardware específico – No puede tomar precauciones para evitar los problemas de desempeño en el hardware específico. – Se tiene una capa adicional que influye en costos de desempeño.

Los microkernels forman parte de la capa más baja del SO. Por consiguiente, se debe aceptar que ellos son dependientes del hardware para la generación de código optimizado. Conclusión. Los microkernels forman el enlace entre un mínimo ¨microconjunto¨ de abstracciones y el procesador al desnudo. La demanda de rendimiento son comparables a microprogramación. Como una consecuencia, los microkernels son inherentemente no portables. A su vez, ellos son la base dependiente del procesador para SO portables.

6. IMPLEMENTACIONES – Synthesis – Spin – Utah-Mach – DP-Mach – Panda – Caché-Kernel – ExoKernel

7. CONCLUSIONES Un microkernel puede capas más altas con un conjunto mínimo de abstracciones apropiadas que son los suficientemente flexibles para mantener las implementaciones de SO absolutos y mantener la explotación de un amplio rango de hardware. Similar a los generadores de optimización de código, los microkernels deben ser construidos por procesador y son inherentemente no portables. El trabajo presentado muestra que es posible lograr buenos desempeños de los microkernels a través de implementaciones específicas de procesador de abstracciones independientes del procesador.