Sistemas operativos -...

316 Sistemas operativos. Una visión aplicada

Aclaración 5.7. En algunas arquitecturas, las direcciones que se usan para acceder a memoria (llamadas ca-pabilities), además de la referencia a la posición de memoria propiamente dicha, incluyen uno o más bits de información de protección, que, entre otras cosas, identifican que se trata de una dirección de acceso a memo-ria. El aspecto interesante de las capabilities es que sólo se pueden modificar estando en modo privilegiado. Por tanto, sólo en dicho modo se pueden generar direcciones válidas de acceso a memoria. Un proceso podrá usar las posiciones de memoria que le ha asignado el sistema operativo, puesto que éste le ha proporcionado las capabilities requeridas para acceder a las mismas. Sin embargo, no podrá acceder a otras direcciones, puesto que la unidad de control del procesador asegura que una capability sólo se puede modificar en modo privilegiado. El mecanismo de capabilities asegura la protección requerida, permitiendo usar direcciones físicas directamente, lo que elimina el problema de las autorreferencias. La reubicación necesaria se puede realizar por software. El único problema de este mecanismo, que ha limitado considerablemente su impacto, es que requiere un procesador con una arquitectura muy específica.

Para terminar esta sección, se plantea la tabla 5.1, que sirve de recapitulación de la misma y muestra una comparativa de los distintos esquemas de gestión de memoria estudiados, mostrando cómo se llevan a cabo las distintas etapas identificadas en la sección 5.2.5.

5.5. MEMORIA VIRTUAL

En prácticamente todos los sistemas operativos de propósito general actuales se usa la técnica de memoria virtual. Hasta el momento, por motivos pedagógicos, se han presentado los diversos esquemas de memoria sin apenas hacer referencia a esta técnica. En esta sección se estudiará esta técnica mostrando cómo se integra con estos esquemas de gestión de memoria. En el primer capítulo ya se presentaron los fundamentos de la memoria virtual, explicando aspectos tales como la jerarquía de memoria o la proximidad de referencias, por lo que no se volverá a incidir en los mismos. Como se apreciará a lo largo de esta sección, la memoria virtual resuelve dos de los objetivos del sistema de memoria identificados al principio del capítulo: ejecutar más procesos de los que caben en la memoria principal, y ejecutar un proceso cuyo mapa no cabe en la memoria. Antes de la aparición de la memoria virtual, esas dos necesidades ya existían y se intentaban resolver de la mejor manera posible, teniendo en cuenta la tecnología presente por entonces. Esta sección, por tanto, co-menzará presentando las técnicas de intercambio y de overlays como precedentes de la memoria virtual. A continuación, se analizarán las diversas políticas de administración de la memoria virtual, especialmente, las estrategias de reemplazo y las políticas de reparto de la memoria entre los procesos.

5.5.1. Intercambio

Como se comentó previamente, la técnica del intercambio (swapping) significó en su momento una manera de permitir que en los sistemas del tiempo compartido existieran más procesos de los que caben en memoria.

Tabla 5.1 Comparativa de los esquemas de gestión de la memoria del sistema.Esquema de gestión Resolución/R.módulos R. regiones R. procesos R. global Registros límite Compilador/montador Montador Cargador Registro base y límite Compilador/montador Montador MMU Segmentación Compilador/montador MMU (seg) Paginación Compilador/montador Montador MMU (pág) Seg. paginada global Compilador/montador MMU (seg) MMU (pág) Seg. paginada local Compilador/montador MMU (seg) MMU (pág) SASOS Compilador/montador Montador Cargador MMU (pág)

Gestión de memoria 317

Se puede considerar que se trata de un mecanismo antecesor de la memoria virtual. En este apartado se pre-sentarán de forma breve los fundamentos de esta técnica.

El intercambio se basa en utilizar un disco o parte de un disco como respaldo de la memoria principal. Esta zona de almacenamiento se denomina dispositivo de swap. Cuando no caben en memoria todos los pro-cesos activos (por ejemplo, debido a que se ha creado uno nuevo), se elige un proceso residente y se copia en swap su imagen en memoria. El criterio de selección puede tener en cuenta aspectos tales como la prioridad del proceso, el tamaño de su mapa de memoria, el tiempo que lleva ejecutando y, principalmente, su estado. Es preferible expulsar (swap out) procesos que estén bloqueados. Cuando se expulsa un proceso, no es nece-sario copiar toda su imagen al dispositivo de swap. Los huecos en el mapa no es preciso copiarlos, ya que su contenido es intrascendente. Tampoco se tiene que copiar el código, puesto que se puede volver a recuperar directamente del ejecutable.

Evidentemente, un proceso expulsado tarde o temprano debe volver a activarse y cargarse en memoria principal (swap in). Sólo se deberían volver a cargar aquellos procesos que estén listos para ejecutar. Esta readmisión en memoria se activará cuando haya espacio de memoria disponible (por ejemplo, debido a que se ha terminado un proceso) o cuando el proceso lleve un cierto tiempo expulsado. Téngase en cuenta que al tratarse de un sistema de tiempo compartido, se debe repartir el procesador entre todos los procesos. Por ello, en numerosas ocasiones hay que expulsar un proceso para poder traer de nuevo a memoria a otro proceso que lleva expulsado un tiempo suficiente.

La estrategia que decide cuándo expulsar un proceso a swap y cuándo reincorporarlo a memoria se co-rresponde con la planificación a medio plazo presentada en el capítulo 4.

En cuanto al dispositivo de swap, hay dos alternativas en la asignación de espacio: • Con preasignación: Al crear el proceso ya se reserva espacio de swap suficiente para albergarlo. Si

el proceso nunca se expulsa, se desperdicia el espacio asignado. • Sin preasignación. Sólo se reserva espacio de swap cuando se expulsa el proceso. Puede haber pro-

blemas si se intenta expulsar un proceso a swap para traer a otro proceso y no hay espacio en el dis-positivo.

Un último aspecto a tener en cuenta es que no debería expulsarse un proceso mientras se estén realizan-do operaciones de entrada/salida por DMA vinculadas a su imagen de memoria, ya que provocaría que el dispositivo accediera al mapa de otro proceso.

5.5.2. Overlays

En los tiempos en los que todavía no se había propuesto la técnica de memoria virtual y las memorias tenían una capacidad limitada, se presentaba con cierta frecuencia el problema de que un determinado programa no cupiera en memoria. Para resolver dentro de lo posible este problema, se ideó la técnica de los overlays. Se trataba de un esquema que no era transparente al programador, puesto que éste tenía que determinar si ciertos módulos de su programa no requerían estar simultáneamente en memoria en tiempo de ejecución y que, por tanto, podrían usar la misma zona de memoria en distintas fases de ejecución del programa. El programador usaba un lenguaje de definición de overlays para notificar al montador esta información. El montador gene-raba un fichero ejecutable en el que incluía automáticamente código para cargar y descargar los módulos del programa. En la llamada desde un módulo a una función definida en otro módulo, el montador incluía código que comprobaba si el módulo destino estaba ya cargado en memoria. En caso de no estarlo, el código inclui-do por el montador cargaba ese módulo, usando para ello, si es necesario, el espacio ocupado por otro módu-lo cuya presencia no se requiere según indica la información suministrada al montador.

5.5.3. Fundamento de la memoria virtual

Como se estudió en el primer capítulo, la memoria en un sistema está organizada como una jerarquía de nive-les de almacenamiento entre los que se mueve la información dependiendo de las necesidades de los procesos


en un determinado instante. La técnica de memoria virtual se ocupa de la transferencia de información entre la memoria principal y la secundaria. La memoria secundaria está normalmente soportada en un disco (o par-tición). Dado que, como se verá más adelante, la memoria virtual se implementa sobre un esquema de pagi-nación, este dispositivo se denomina dispositivo de paginación. También se usa el término dispositivo de swap. Aunque este término proviene de la técnica del intercambio, por tradición se usa frecuentemente y se utilizará indistintamente en esta exposición. En cualquier caso, hay que resaltar que la memoria secundaria no sólo está formada por el dispositivo de paginación, sino que también forma parte de la misma el sistema de ficheros. Téngase en cuenta que, como se analizará en esta sección, al ser expulsadas, algunas páginas se transferirán al dispositivo de paginación, mientras que otras lo harán al sistema de ficheros.

Es importante recordar en este punto que, como se explicó en el primer capítulo, el buen rendimiento del sistema de memoria virtual está basado en que los procesos presentan la propiedad de proximidad de referencias. Esta propiedad permite que un proceso genere muy pocos fallos aunque tenga en memoria prin-cipal sólo una parte de su imagen de memoria (conjunto residente). El objetivo del sistema de memoria vir-tual es intentar que la información que está usando un proceso en un determinado momento (conjunto de trabajo) esté residente en memoria principal, es decir, que el conjunto residente del proceso contenga su con-junto de trabajo. Algunos beneficios del uso de memoria virtual son los siguientes:

• Se produce un aumento del grado de multiprogramación al no ser necesario que todo el mapa de memoria de un proceso esté en memoria principal para poder ejecutarlo. Este aumento implica una mejora en el rendimiento del sistema. Sin embargo, como se analizó en el segundo capítulo, si el grado de multiprogramación se hace demasiado alto, el número de fallos de página se dispara y el rendimiento del sistema baja drásticamente. Esta situación se denomina hiperpaginación y se estu-diará más adelante.

• Se pueden ejecutar programas más grandes que la memoria principal disponible. Hay que resaltar que el objetivo de la memoria virtual no es acelerar la ejecución de un programa. En

algunos casos, puede hacerlo, especialmente, en situaciones donde el proceso no accede a todo su código o a todos sus datos durante su ejecución, no siendo necesario, por tanto, leerlos del ejecutable. Sin embargo, en otras ocasiones, puede incluso ralentizar la ejecución, debido a la sobrecarga asociada a las transferencias entre la memoria principal y la secundaria. Esto hace que esta técnica no sea apropiada para sistemas de tiempo real, además de por hacer que sea poco predecible el comportamiento de los procesos.

Como se ha analizado en los apartados anteriores, la memoria virtual se construye generalmente sobre un esquema de paginación, ya sea paginación simple o segmentación paginada. Por tanto, las unidades de información que se transfieren entre la memoria principal y la secundaria son páginas. Las transferencias desde la memoria secundaria hacia la principal se realizan normalmente bajo demanda (paginación por de-manda). Cuando un proceso necesita acceder a una página que no está en memoria principal (a lo que se denomina fallo de página), el sistema operativo se encarga de transferirla desde la memoria secundaria. Si al intentar traer la página desde memoria secundaria, se detecta que no hay espacio en la memoria principal (no hay marcos libres), será necesario expulsar una página de la memoria principal y transferirla a la secundaria. Por tanto, las transferencias desde la memoria principal hacia la secundaria se realizan normalmente por ex-pulsión. El algoritmo para elegir qué página debe ser expulsada se denomina algoritmo de reemplazo y se analizará más adelante.

Dado que se está usando la paginación para construir un esquema de memoria virtual, se puede usar in-distintamente el término de dirección lógica y el de dirección virtual para referirse a las direcciones que genera un programa.

Para construir un esquema de memoria virtual sobre un procesador que ofrezca paginación, se utiliza el bit de la entrada de la tabla de páginas que indica si la página es válida. Estarán marcadas como inválidas todas las entradas correspondientes a las páginas que no están residentes en memoria principal en ese instan-te. Dado que se utiliza el bit validez para marcar la ausencia de una página y este mismo bit también se usa para indicar que una página es realmente inválida (una página que corresponde a un hueco en el mapa), es necesario que el sistema operativo almacene información asociada a la página para distinguir entre esos dos casos. En caso de que la página sea válida pero no residente, el sistema operativo también deberá guardar información de en qué bloque de la memoria secundaria está almacenada la página. De esta forma, cuando se


produzca un acceso a una de estas páginas, se producirá una excepción (fallo de página) que activará al sis-tema operativo, que será el encargado de traerla desde la memoria secundaria.

5.5.4. Ciclo de vida de una página

Antes de analizar los distintos aspectos vinculados con la memoria virtual, es conveniente analizar cómo evo-luciona una página en un sistema con memoria virtual, dependiendo de a qué tipo de región pertenece, fiján-dose en dos características de la misma: si es privada o compartida y si tiene soporte o es anónima.

• Página de una región compartida con soporte en un fichero. Cada vez que se produzca un fallo al acceder a esta página por no estar presente en memoria principal, habrá que leerla del fichero que la contiene. Por otra parte, al ser expulsada estando modificada, habrá que volverla a escribir en el fi-chero, puesto que los cambios sobre una región compartida deben revertir al fichero. La figura 5.67 muestra cómo es la evolución de este tipo de páginas.

• Página de una región privada con soporte en un fichero. Mientras no se modifique la página, es-tará vinculada al soporte y todos los fallos se servirán leyendo del fichero. En cuanto se modifique una vez, queda desvinculada del soporte original, y al ser expulsada, se escribirá en swap. Los fallos posteriores se servirán de swap, y las expulsiones que encuentren la página modificada la escribirán en swap. Esta es la esencia de una región privada: los cambios sobre la misma no afectan al soporte original. Para entender la utilidad de este modo de operación, recuerde que se utiliza con la región de datos con valor inicial de un programa o de una biblioteca dinámica. Después de acceder a una va-riable global con valor inicial para modificarla, cuando sea expulsada la página que la contiene, no podemos volver a escribirla en el fichero ejecutable, puesto que estaríamos cambiando el propio pro-grama. La figura 5.68 muestra la evolución de una página de estas características.

• Página de una región anónima, ya sea privada o compartida. Por motivos de seguridad, cuando se accede por primera vez a una página de este tipo, se rellena con ceros el marco de página usado para la misma, no requiriendo un acceso a disco. Si la página se expulsa sin ser modificada (lo cual es bastante improbable puesto que, al no tener un valor inicial, lo más habitual es que el primer acce-so sea de escritura), no es necesario escribirla en el disco. El siguiente fallo volverá a rellenar el mar-co elegido con ceros. En cuanto se modifique una vez la página, al ser expulsada, se escribirá en swap. Los fallos posteriores se servirán de swap y las expulsiones que encuentren la página modifi-cada la escribirán en swap. Recuerde que la región de datos sin valor inicial de un programa o de una biblioteca dinámica son de este tipo, teniendo, además, carácter privado. También entra en esta cate-goría una zona de memoria compartida que no esté basada en un fichero. La figura 5.69 muestra la evolución de una página de este tipo.

5.5.5. Políticas de administración de la memoria virtual

Como se analizó en el primer capítulo, el modo de interacción entre dos niveles de la jerarquía queda defini-do por un conjunto de políticas que establecen de qué forma se realizan las transferencias entre ambos. En el

Fichero

MemoriaFallo

Expulsión ymodificada

Figura 5.67 Ciclo de vida de una página de una región compartida con soporte.


caso de la memoria virtual, los niveles implicados son la memoria principal y la secundaria, y las políticas que definen el comportamiento de un sistema de memoria virtual son las siguientes:

• Política de localización. Permite localizar una determinada página dentro de la memoria secundaria. • Política de extracción. Define cuándo se transfiere una página desde la memoria secundaria a la

principal. • Política de ubicación. Si hay varios marcos libres, establece cuál de ellos se utiliza para almacenar

la página que se trae a memoria principal. • Política de reemplazo. En caso de que no haya marcos libres, determina qué página debe ser des-

plazada de la memoria principal para dejar sitio a la página entrante. • Política de actualización. Rige cómo se propagan las modificaciones de las páginas en memoria

principal a la memoria secundaria. • Política de reparto de espacio entre los procesos. Decide cómo se reparte la memoria física entre

los procesos existentes en un determinado instante. Sobre las políticas de ubicación y de actualización hay poco que comentar. Con respecto a la primera,

en principio, se puede usar cualquier marco libre para albergar una página leída de la memoria secundaria. Sin embargo, algunos sistemas operativos intentan seleccionar el marco de manera que se mejore el rendi-miento de la memoria caché. Esta técnica, denominada coloración de páginas, intenta que las páginas resi-dentes en memoria en un momento dado estén ubicadas en marcos cuya distribución en las líneas de la caché sea lo más uniforme posible. En cuanto a la política de actualización, dada la enorme diferencia entre la velo-cidad de transferencia de la memoria principal y la de la secundaria, no es factible usar una política de actua-lización inmediata, utilizándose, por tanto, una política de escritura diferida: sólo se escribirá una página a memoria secundaria cuando sea expulsada de la memoria principal estando, además, modificada. En las próximas secciones se analizarán las cuatro políticas restantes.

Memoria

Fallos y expulsionesuna vez modificada


Swap

Fallo (mientras nomodificada una vez)

Rellenarcon ceros

Figura 5.69 Ciclo de vida de una página de una región anónima.

Fichero

Memoria

Fallos y expulsionesuna vez modificada


Swap

Fallo (mientras nomodificada una vez)

Figura 5.68 Ciclo de vida de una página de una región privada con soporte.


5.5.6. Política de localización

Como se comentó al principio de esta sección, la paginación por demanda se basa en hacer creer a la MMU que la página no residente es inválida para que produzca una excepción de fallo de página cuando se acceda a la misma. De esta manera, el sistema operativo puede activarse para tratar la excepción y traer la página de memoria secundaria. Sin embargo, es necesario que el sistema operativo pueda saber si la página realmente es válida, y, en caso de serlo, cómo localizarla.

Con respecto a la determinación de la validez, la mayoría de los sistemas operativos consultan la tabla de regiones buscando en qué región está englobada la dirección de fallo. Dado que un proceso puede tener un número elevado de regiones, para agilizar la operación de comprobar si la dirección es válida, la tabla de re-giones se organiza como una estructura de datos que permita una búsqueda eficiente y elimine la necesidad de un recorrido lineal de la tabla. Habitualmente, se utiliza un árbol binario ordenado por la dirección de co-mienzo de cada región. De esta forma, el tiempo de búsqueda es logarítmico con respecto al número de re-giones del proceso en vez de lineal. Además, esta estructura permite realizar eficientemente operaciones de inserción y borrado de regiones.

En caso de que la dirección que provoca el fallo no encaje en ninguna región, se trata de una página in-válida, que corresponde a un hueco en el mapa de memoria del proceso, por lo que se abortará el proceso o se le mandará una señal. En el ejemplo mostrado en la figura 5.70, la sexta entrada de la tabla de páginas se co-rresponde con un hueco en el mapa del proceso. Si el proceso intenta acceder a una dirección incluida en ese hueco, como la 20500, se producirá una excepción de fallo de página, dentro de cuyo tratamiento el sistema operativo determinará que el acceso es inválido, al no estar incluida en ninguna región la dirección de fallo.

Para entender el proceso de localización, hay que analizar qué cuatro casos se pueden presentar para una página válida, como se muestra en la figura 5.70.

• Página residente en memoria. Se trata de una página a la que se ha accedido y en este momento está residente en memoria. La entrada de la tabla de páginas identifica al marco que contiene la pági-na. La primera entrada de la tabla de páginas de la figura se corresponde con este caso, estando al-macenada en el marco 4.

08192

R-X Comp.F Bl. inicial 0

BCP de P1

t. de regiones

t. páginas

00004 V R-X00000 I 000

Mapa de memoria de P1

Región 1 (R-X)

Región 2 (RW-)

Región 3 (RW-)

.........

0

8192

16384

Memoria

P gina 0 de P1á

Región 1 (R-X)

Región 3 (RW-)

.........

0

8192

16384

00001 I SW1

Marco 0Marco 1Marco 2Marco 3Marco 4

......................... ........

Fichero

20480

Cód. 0Cód. 1DVI 0DVI 1

.........81928192

RW- Privada F Bl. inicial 2

163844096

RW- Privada An nimaó

Fichero F

00000 I 00000000 I 000

Fichero

Bloq. 0

.........

Swap (SW1)

Bloq. 1Bloq. 2Bloq. 3

.........00000 I 000

Figura 5.70 Posibles ubicaciones de una página.


• Página no residente almacenada en un fichero. Corresponde a una página no residente cuyo con-tenido está almacenado en un bloque de un fichero. Cuando se produzca un fallo, el sistema operati-vo localizará la región a la que pertenece la página y podrá comprobar en el descriptor de la región que se trata de una región con soporte en un fichero, obteniendo información acerca de qué fichero se trata y a qué parte del mismo corresponde la región. Calculando el desplazamiento de la página con respecto al inicio de la región y sabiendo en qué posición del fichero comienza la región, se pue-de determinar en qué bloque del fichero se ubica la página. La segunda y cuarta entradas de la tabla de páginas de la figura son ejemplos de esta situación. La segunda entrada está vinculada a la región 1. El descriptor de esa región indica que se trata de una región con soporte en el fichero F, estando ubicada al principio del mismo. Dado que se trata de la segunda página de esa región, habrá que leer el bloque 1 del disco para obtener su contenido. En cuanto a la cuarta entrada, está incluida en la re-gión 2, cuyo descriptor indica que también tiene soporte en el fichero F, pero, comenzando en el bloque 2 del mismo. Como se trata de la segunda página de esta región, habrá que leer el bloque 3 del disco para obtener su contenido.

• Página no residente de tipo anónima. Se trata de una página no residente perteneciente a una re-gión sin soporte. Cuando se produzca un fallo al acceder a esta página y se detecta que la región es de este tipo, basta con buscar un marco libre y, por motivos de seguridad, rellenarlo con ceros. La quinta entrada de la figura 5.70 corresponde a una página de este tipo. Cuando se produzca un fallo al intentar acceder a la misma, se detectará que pertenece a una región anónima y se procederá a re-llenarla con ceros. Es interesante resaltar que en el sistema operativo Linux, en el inicio del sistema y durante todo el tiempo que está arrancado, se reserva un marco de página de sólo lectura relleno con ceros. De esta forma, en vez de rellenar la página con ceros explícitamente, se comparte, usando COW, que será explicado más adelante, hasta que el programa haga alguna modificación sobre la misma.

• Página en swap. Como se explicó anteriormente, las páginas de las regiones sin soporte y de las re-giones privadas, una vez modificadas, si se expulsan, son escritas en el dispositivo de paginación. En este caso, la información de ubicación de la página en el disco no puede almacenarse en el descriptor de la región, a no ser que habilitemos espacio para cada una de las páginas de la misma. En su lugar, la mayoría de los sistemas operativos optan por almacenar la información de ubicación en el swapdentro de la propia entrada de la tabla de páginas. Esta información suele consistir en un identifica-dor del dispositivo de swap, ya que, normalmente, se permiten múltiples dispositivos de swap en el sistema, junto con un número de bloque dentro del dispositivo. Nótese que, dado que cuando una en-trada de la tabla de páginas es inválida el valor de los campos de la misma es intrascendente, se aprovecha para almacenar la información de swap en esos campos. La tercera entrada de la tabla de páginas de la figura 5.70 corresponde a este caso. Se trata de una página de una región privada con soporte en fichero que ya ha sido modificada alguna vez y que, por tanto, está vinculada al swap.Cuando se produzca un fallo sobre esta página, después de realizar la validación de la dirección, se detectará que la entrada de la tabla de páginas tiene un valor distinto de cero (en los demás casos de páginas válidas pero no residentes, se habrán rellenado con ceros todos los campos de la entrada de la tabla de páginas). Se usará el valor almacenando en la entrada (en este caso, dispositivo SW1 y bloque 1 del mismo) para saber qué bloque leer.

5.5.7. Política de extracción

La memoria virtual, en su forma ortodoxa, opera bajo demanda: sólo se trae a memoria principal una página cuando el proceso accede a la misma. Sin embargo, casi todos los sistemas operativos implementan algún tipo de agrupamiento de páginas o de lectura anticipada de páginas, de manera que cuando se produce un fallo de página, no sólo se trae a memoria la página involucrada, sino también algunas páginas próximas a la misma, puesto que, basándose en la propiedad de proximidad de referencias que caracteriza a los programas, es posible que el proceso las necesite en un corto plazo de tiempo. Estas técnicas suelen englobarse bajo el término de prepaginación. La efectividad de las mismas va a depender de si hay acierto en esta predicción,


es decir, si finalmente las páginas traídas van a ser usadas, puesto que, en caso contrario, se ha perdido tiem-po en traerlas, expulsando, además, de la memoria principal a otras páginas que podrían haber sido más úti-les. Hay que resaltar que en el sistema de ficheros también se utilizan técnicas de lectura anticipada, lo cual no puede sorprender por la fuerte interacción, y progresiva fusión, entre estos dos componentes.

Dado que en la fase de arranque de un programa es donde más se hace patente la sobrecarga de la me-moria virtual, al producirse numerosos fallos mientras el conjunto de trabajo del programa va cargándose en memoria, en algunos sistemas operativos se realiza un seguimiento de los primeros segundos de la ejecución del programa, guardando información sobre los fallos de página que provoca. De esta manera, cuando arran-ca nuevamente un programa, se puede realizar una lectura anticipada dirigida de las páginas que probable-mente va a usar el mismo durante su fase inicial.

Volviendo a la paginación por demanda, que es la médula espinal de la memoria virtual, la mayor parte de la lógica que controla esta técnica está articulada alrededor de la rutina del tratamiento del fallo de página. A continuación, se analizan con más detalle las operaciones vinculadas con un fallo de página.

Tratamiento del fallo de páginaLa paginación por demanda está dirigida por la aparición de excepciones de fallo de página que indican al sistema operativo que debe traer una página de memoria secundaria a primaria, puesto que un proceso la re-quiere. A continuación, se especifican los pasos típicos en el tratamiento de un fallo de página:

• La MMU del procesador produce una excepción, dejando, habitualmente, en un registro especial la dirección que provocó el fallo.

• Se activa el sistema operativo que comprueba si se trata de una dirección correspondiente a una página realmente inválida o se corresponde con una página ausente de memoria. Para ello, como se comentó previamente, accederá a la tabla de regiones para encontrar a qué región pertenece la direc-ción que produjo el fallo. Si no pertenece a ninguna, la página es inválida, por lo que se aborta el proceso o se le manda una señal. En caso contrario, se realizan los pasos que se describen a conti-nuación. Evidentemente, si la dirección es del sistema y el proceso estaba en modo usuario cuando se produjo el fallo, será también inválida.

• Se consulta la tabla de marcos para buscar uno libre. • Si no hay un marco libre, se aplica el algoritmo de reemplazo para seleccionar la página que se ex-

pulsará. El marco seleccionado se desconectará de la página a la que esté asociado poniendo como inválida la entrada correspondiente. Si la página está modificada, previamente hay que escribir su contenido a la memoria secundaria:

⎯ Si la página pertenece a una región de tipo compartida y con soporte en fichero, hay que es-cribirla en el bloque correspondiente del fichero.

⎯ En el resto de los casos, hay que escribirla en swap, almacenándose en la entrada de la tabla de páginas la identificación del bloque de swap que contiene la página.

• Una vez que se obtiene el marco libre, ya sea directamente o después de una expulsión, se inicia la carga de la nueva página sobre el marco y, al terminar la operación, se rellena la entrada correspon-diente a la página para que esté marcada como válida y apunte al marco utilizado. La localización de la página se realizará tal como se explicó en el apartado anterior.

Téngase en cuenta que, en el peor de los casos, un fallo de página puede causar dos operaciones de en-trada/salida al disco. En contraste, puede no haber ninguna operación sobre el disco si hay marcos libres o la página expulsada no está modificada y, además, la página que causó el fallo se corresponde con una región anónima que todavía no se ha modificado ninguna vez.

Para terminar, es conveniente realizar algunas consideraciones sobre el caso de que se produzca un fallo de página cuando el proceso estaba en modo sistema:

• Si la dirección de fallo corresponde a una dirección lógica de usuario y se estaba ejecutando una lla-mada al sistema, el fallo se produce debido a que se ha accedido al mapa de usuario del proceso para leer o escribir algún parámetro de la llamada. El tratamiento del fallo es el habitual (comprobar si está incluido en alguna región, buscar un marco libre, etc.)


• En caso de que la dirección de fallo corresponda a una dirección lógica de usuario y se estuviera eje-cutando una interrupción, se trataría de un error en el código del sistema operativo, puesto que, dado que una interrupción tiene un carácter asíncrono y no está directamente vinculada con el proceso en ejecución, no debe acceder al mapa de usuario del proceso en ninguna circunstancia. El tratamiento sería el habitual ante un error en el sistema operativo (podría ser, por ejemplo, sacar un mensaje por la consola y realizar una parada ordenada del sistema operativo).

• Si la dirección de fallo es una dirección lógica de sistema, a su vez, podrían darse varios casos: ⎯ Si se trata de un sistema operativo que permite que páginas del sistema se expulsen a disco, se

comprobaría si la dirección corresponde a una de esas páginas y, si es así, se leería de disco. ⎯ Si se usa un procesador que tiene una tabla única para direcciones de usuario y de sistema, y

en el que, por tanto, se duplican las entradas correspondientes al sistema operativo en las ta-blas de páginas de todos los procesos, el fallo puede deberse a que se ha añadido una nueva entrada del sistema en la tabla de un proceso, pero no se ha propagado a los restantes. De esta forma, la propagación de este cambio se hace también por demanda, no tratándose de un error.

⎯ En todos los demás casos, se correspondería con un error en el código del sistema operativo.

Creación de tablas de páginas por demandaSi se analiza el proceso de localización de las páginas explicado previamente, se puede apreciar en el mismo que las entradas de la tabla de páginas sólo se usan cuando las páginas están residentes, o cuando están alma-cenadas en swap, siendo la tabla de regiones el elemento clave de la gestión. Basándose en este hecho, se puede extender la política de operación bajo demanda a la propia creación de las tablas de páginas interme-dias requeridas en los sistemas de paginación multinivel.

De la misma manera que cuando se crea una región en un sistema con memoria virtual no es necesario asignarle marcos hasta que no se acceda a las páginas de la región, como se analizará en la sección 5.5.14, se puede diferir la creación de las tablas de páginas intermedias requeridas por la región hasta que se produzca ese acceso. De esta forma, el proceso inicialmente sólo dispone de la tabla de páginas de nivel superior con todas las entradas marcadas como inválidas. Cuando se produce un fallo y se detecta que las tablas de pági-nas intermedias requeridas por esa página no se han creado todavía, se reserva memoria para las mismas en ese momento, iniciándolas como inválidas. En la figura 5.71 se muestra un ejemplo de uso de este mecanis-mo. En el mismo, el proceso sólo ha accedido a dos páginas. El primer acceso provocó un fallo que se produ-

Memoria

de primer nivel

Tablas de páginasde segundo nivel

Tabla de páginas

V

I

I

II

I

V

I

II

I

V

08192


BCP de P1

t. de regiones

t. páginas

81928192


.............

Figura 5.71 Creación de tablas de páginas por demanda.


jo en la tabla de primer nivel. Una vez que se comprueba que la dirección es válida usando la tabla de regio-nes, se reserva la tabla de segundo nivel, además del propio marco que alojará la página. El segundo acceso ha provocado un fallo en la tabla de segundo nivel, por tanto, sólo requiere reservar el marco para la página.

Con este mecanismo, la tabla de regiones es el elemento conductor del proceso y sólo es necesario tener desplegadas las tablas de páginas para las páginas residentes, lo cual resulta especialmente beneficioso para procesos con un espacio de direcciones disperso. Realmente, con el esquema que hemos planteado, también haría falta tener desplegadas las tablas si contienen entradas que se refieren a bloques de swap, aunque este último requisito podría eliminarse si se almacena esta información en otra estructura de datos, como, por ejemplo, la tabla de regiones.

5.5.8. Política de reemplazo

Una de las políticas principales de un sistema de memoria virtual, y una de las que puede afectar más a su rendimiento, es la que determina qué página expulsar cuando hay que traer otra de memoria secundaria y no hay espacio libre. Este mismo problema se presenta en todos los niveles de la jerarquía y, aunque, en cierta medida, hay similitudes, en cada nivel se presentan aspectos específicos debido a las diferencias intrínsecas entre los distintos componentes de memoria usados en la jerarquía, en cuanto a su velocidad y capacidad. Por otra parte, hay que resaltar que el problema de gestionar la transferencia de información entre la memoria principal y el disco no se restringe al sistema de memoria virtual, sino que aparece en la gestión de la caché del sistema de ficheros, así como en los sistemas gestores de bases de datos. Aunque muchos algoritmos usa-dos en estos ámbitos son similares a los utilizados en la memoria virtual, hay que tener en cuenta que existe una importante diferencia entre el modo de operación del sistema de ficheros, o de un gestor de base de da-tos, y el sistema de memoria. En los primeros, existe una petición explícita por parte de la aplicación para acceder a la información, pudiendo, por tanto, el sistema operativo (o el gestor de base de datos) tener control sobre qué accesos se van realizando. En cambio, en la memoria, el proceso accede directamente a la misma sin que el sistema operativo sea consciente de ello. El sistema operativo sólo toma control cuando se produce un fallo de página.

Existen numerosos trabajos, tanto teóricos como experimentales, sobre algoritmos de reemplazo de páginas. En esta sección se describirán los algoritmos de reemplazo más habituales, intentando mostrar las últimas tendencias en este campo que, después de un cierto periodo con pocas innovaciones, ha presentando importantes contribuciones en los últimos tiempos.

Las estrategias de reemplazo se pueden clasificar en dos categorías: reemplazo global y reemplazo lo-cal. Con una estrategia de reemplazo global se puede seleccionar para satisfacer el fallo de página de un pro-ceso un marco que actualmente tenga asociada una página de otro proceso. Esto es, un proceso puede quitarle un marco de página a otro. La estrategia de reemplazo local requiere que para servir el fallo de página de un proceso sólo puedan usarse marcos de páginas libres o marcos ya asociados al proceso.

Todos los algoritmos que se describirán a continuación pueden utilizarse tanto para estrategias globales como locales. Cuando se aplica un algoritmo determinado utilizando una estrategia global, el criterio de eva-luación del algoritmo se aplicará a todas las páginas en memoria principal. En el caso de una estrategia local, el criterio de evaluación del algoritmo se aplica sólo a las páginas en memoria principal que pertenecen al proceso que causó el fallo de página. La descripción de los algoritmos, por tanto, se realizará sin distinguir entre los dos tipos de estrategias.

El objetivo básico de cualquier algoritmo de reemplazo es minimizar la tasa de fallos de página, inten-tando además que la sobrecarga asociada a la ejecución del algoritmo sea tolerable y que no se requiera una MMU con características específicas. En principio, de manera intuitiva, parece razonable pensar en tres fac-tores a la hora de diseñar un algoritmo de estas características:

• Tiempo de residencia. Tener en cuenta el tiempo que lleva la página presente en memoria a la hora de expulsar una página. Como se analizará a continuación, no es un buen criterio.

• Frecuencia de uso. Basarse en cuántas veces se ha accedido a una página para decidir cuál reempla-zar. Aunque el criterio es razonable, tiene ciertas limitaciones, que se analizarán enseguida.


• Frescura de la página. Utilizar como criterio si la página se ha usado recientemente. Como se ex-plicará a continuación, es el criterio básico de este tipo de algoritmos.

Algoritmo de reemplazo óptimoEl algoritmo óptimo, denominado también MIN, debe generar el mínimo número de fallos de página. Por ello, la página que se debe reemplazar es aquélla que tardará más tiempo en volverse a usar.

Evidentemente, este algoritmo es irrealizable, ya que no se puede predecir cuáles serán las siguientes páginas a las que se va a acceder. Este algoritmo sirve para comparar el rendimiento de los algoritmos que sí son factibles en la práctica.

Algoritmo FIFO (First Input/First Output, primera en entrar/primera en salir) Una estrategia sencilla e intuitivamente razonable es seleccionar para la sustitución la página que lleva más tiempo en memoria, es decir, basarse en el tiempo de residencia. La implementación de este algoritmo es simple. Además, no necesita ningún apoyo hardware especial. El sistema operativo debe mantener una lista de las páginas que están en memoria, ordenada por el tiempo que llevan residentes. En el caso de una estrate-gia local, se utiliza una lista por cada proceso. Cada vez que se trae una nueva página a memoria, se pone al final de la lista. Cuando se necesita reemplazar, se usa la página que está al principio de la lista.

Sin embargo, el rendimiento del algoritmo no es bueno en muchas ocasiones. La página que lleva más tiempo en memoria puede contener instrucciones o datos a los que se accede con frecuencia. Poniendo un ejemplo extremo, piense en un programa pequeño, cuyo código cabe en una sola página. Lo razonable sería que esa página nunca se expulsase, pero, con el algoritmo FIFO se expulsaría con bastante frecuencia.

En determinadas situaciones este algoritmo presenta un comportamiento sorprendente, conocido como la anomalía de Belady. Intuitivamente, parece que cuantos más marcos de página haya en el sistema, menos fallos de página se producirán. Sin embargo, ciertos patrones de referencias causan que este algoritmo tenga un comportamiento opuesto. El descubrimiento de esta anomalía resultó al principio sorprendente y llevó al desarrollo de modelos teóricos para analizar los sistemas de memoria virtual. En la práctica, esta anomalía es sólo una curiosidad, que demuestra que los sistemas pueden tener a veces comportamientos inesperados.

Algoritmo LRU (Least Recently Used, menos recientemente usada) El algoritmo LRU está basado en el principio de proximidad temporal de referencias: si es probable que se vuelvan a referenciar las páginas a las que se ha accedido recientemente, la página que se debe reemplazar es aquélla a la que no se ha hecho referencia desde hace más tiempo. Dicho de otra forma, se intenta predecir el futuro próximo usando el pasado reciente. Se basa, por tanto, en un criterio de frescura de la página.

El algoritmo LRU no sufre la anomalía de Belady. Pertenece a una clase de algoritmos denominados algoritmos de pila. La propiedad de estos algoritmos es que las páginas residentes en memoria para un siste-ma con n marcos de página son siempre un subconjunto de las que habría en un sistema con n+1 marcos. Esta propiedad asegura que un algoritmo de este tipo nunca sufrirá la anomalía de Belady.

Hay un aspecto sutil en este algoritmo cuando se considera su versión global. A la hora de seleccionar una página no habría que tener en cuenta el tiempo de acceso real, sino el tiempo lógico de cada proceso. O sea, habría que seleccionar la página que haya sido menos recientemente usada teniendo en cuenta el tiempo lógico de cada proceso.

El algoritmo LRU se utiliza muy frecuentemente para la gestión de la caché del sistema de ficheros. Sin embargo, una implementación exacta en un sistema de memoria virtual es difícil, ya que requiere un conside-rable apoyo hardware. Una implementación del algoritmo podría basarse en lo siguiente:

• El procesador gestiona un contador que se incrementa en cada referencia a memoria. Cada posición de la tabla de páginas ha de tener un campo de tamaño suficiente para que quepa el contador.

• Cuando se hace referencia a una página, la MMU copia el valor actual del contador en la posición de la tabla correspondiente a esa página (realmente, debería ser en la TLB, para evitar un acceso a la ta-bla por cada referencia).

• Cuando se produce un fallo de página, el sistema operativo examina los contadores de todas las páginas residentes en memoria y selecciona como víctima aquélla que tiene el valor menor.


Esta implementación es factible, aunque requiere un hardware complejo y muy específico, y eso no es una buena idea. Como ya hemos comentado, y reiteraremos, varias veces a lo largo de los diversos capítulos del libro, un sistema operativo, con el fin de facilitar su adaptación a distintos procesadores, debería seguir una política de mínimos requisitos con respecto al hardware. Lo que se precisa es un algoritmo con unas prestaciones similares, pero que no requiera ningún hardware específico.

Algoritmo del relojEl algoritmo de reemplazo del reloj (o de la segunda oportunidad) es una modificación sencilla del FIFO, que evita el problema de que una página muy utilizada sea eliminada por llevar mucho tiempo residente, pro-porcionando unas prestaciones similares a las del algoritmo LRU, sin requerir un hardware específico.

En este algoritmo, cuando se necesita reemplazar una página, se examina el bit de referencia de la pági-na más antigua (la primera de la lista en orden FIFO). Si no está activo, se usa esta página para el reemplazo. En caso contrario, se le da una segunda oportunidad a la página, poniéndola al final de la lista y desactivando su bit de referencia. Por tanto, se la considera como si acabara de llegar a memoria. La búsqueda continuará hasta que se encuentre una página con su bit de referencia desactivado. Si todas las páginas tienen activado su bit de referencia, el algoritmo se convierte en FIFO.

Para implementar este algoritmo se puede usar una lista circular de las páginas residentes en memoria, en vez de una lineal (en el caso de una estrategia local, se utiliza una lista circular por cada proceso). Existe un puntero que señala en cada instante al principio de la lista. Cuando llega a memoria una página, se coloca en el lugar donde señala el puntero y, a continuación, se avanza el puntero al siguiente elemento de la lista. Cuando se busca una página para reemplazar, se examina el bit de referencia de la página a la que señala el puntero. Si está activo, se desactiva y se avanza el puntero al siguiente elemento. El puntero avanzará hasta que se encuentre una página con el bit de referencia desactivado. Esta forma de trabajo imita al comporta-miento de un reloj donde el puntero que recorre la lista se comporta como la aguja del reloj. Debido a ello, esta estrategia se denomina algoritmo del reloj. La figura 5.72 muestra un ejemplo de este algoritmo, donde se puede apreciar que a las dos primeras páginas revisadas se les da una segunda oportunidad por tener el bit de referencia a uno, siendo seleccionada la tercera para la expulsión.

Ref = 1

Ref = 0

Ref = 1

Ref = 1

Ref = 0

Ref = 0

Ref = 1

Ref = 0

Ref = 1

Ref = 0

Inicio

Expulsada

Figura 5.72 Ejemplo del algoritmo del reloj.


Como se comentó previamente, se trata de un algoritmo sencillo, que sólo requiere que el procesador gestione un bit de referencia, que suele ser lo habitual (incluso en procesadores que no gestionan este bit es relativamente sencillo implementarlo, simulándolo por software). Como el algoritmo LRU, también está ba-sado en la frescura de la página, proporcionando un rendimiento similar. Esto ha hecho que, con pequeñas variaciones específicas, sea el algoritmo utilizado en la mayoría de los sistemas operativos actuales.

Algoritmo LFU (Least Frequently Used, menos frecuentemente usada) Existe un número incontable de algoritmos de reemplazo en la literatura sobre gestión de memoria, por ello no tiene sentido hacer un repaso exhaustivo de los mismos en esta sección. Sin embargo, se ha considerado conveniente hacer una breve reseña de este algoritmo, puesto que, aunque no proporciona una buena solución al problema, tiene en cuenta un factor que no era tomado en consideración en los algoritmos presentados: la frecuencia de uso.

La idea de este algoritmo es expulsar la página residente que menos accesos ha recibido. El problema de esta técnica es que una página que se utilice con mucha frecuencia en un intervalo de ejecución del pro-grama obtendrá un valor del contador muy alto, no pudiendo ser expulsada en el resto de la ejecución del programa.

Dada la escasa utilidad del algoritmo, no se entrará más en detalle sobre su implementación, aunque hay que resaltar que, como ocurría con el algoritmo LRU, necesitaría una MMU específica que gestionase un contador de referencias, o bien usar una versión aproximada del mismo, que gestionara el contador mediante muestreos periódicos del bit de referencia.

Hay que resaltar que usar únicamente la frecuencia no es una buena estrategia, pero que, como se verá a continuación, olvidarse totalmente de la frecuencia, como sucede con el algoritmo LRU, tampoco es una buena idea.

Más allá del LRUDurante mucho tiempo se ha considerado que el algoritmo LRU, y su aproximación práctica, el algoritmo del reloj, era la mejor solución posible al problema del reemplazo. Sin embargo, el estudio de su comportamiento ha detectado algunos problemas de rendimiento ante situaciones relativamente frecuentes. Una de estas situa-ciones aparece cuando se accede una sola vez a un conjunto de páginas. A estas páginas no se volverá a ac-ceder, pero, sin embargo, se quedarán en memoria hasta que sean expulsadas siguiendo el orden LRU. Este tipo de situaciones aparece con cierta frecuencia, especialmente, cuando se accede a ficheros proyectándolos en memoria, como se analizará en la sección 5.5.15. Imagine, por ejemplo, que en el sistema se ejecuta un programa que realiza una copia de seguridad de un conjunto de ficheros usando la técnica de la proyección en memoria para acceder a los mismos. Aunque sólo se acceda una vez a cada página de cada uno de estos fi-cheros, va a permanecer en memoria conforme a la estrategia LRU, impidiendo que otras páginas realmente útiles puedan estar en memoria. Se podría decir que ese acceso único a los ficheros planteado en el ejemplo ha contaminado la memoria.

El problema surge debido a que el algoritmo LRU se basa sólo en el criterio de frescura de la página, olvidando totalmente la frecuencia de accesos a la misma, que también es un indicador adecuado del interés de la página, siempre que no se use como criterio único. Para intentar adaptarse a esta circunstancia, surgió el algoritmo LRU/2 (realmente, la familia de algoritmos LRU/k), que usa el criterio LRU convencional, pero aplicado al penúltimo acceso (de ahí viene el 2 del nombre), es decir, se expulsa a aquella página cuyo penúltimo acceso ha sido menos reciente. Esta estrategia haría que en el ejemplo planteado las páginas de los ficheros desaparecieran rápidamente de la memoria al no producirse un segundo acceso a las mismas.

En los últimos tiempos ha habido una proliferación de algoritmos, tanto en el ámbito de la gestión de memoria como en los de los sistemas de ficheros y las bases de datos, que han intentado conciliar estos crite-rios de frescura y frecuencia. La mayoría de estos algoritmos son complejos e incluyen algunos parámetros de configuración (tales como plazos de tiempo o tamaños) que son difíciles de ajustar satisfactoriamente en un sistema de propósito general.

En cualquier caso, parece que hay un acuerdo general sobre que uno de los mejores algoritmos es el ARC (Adaptive Replacement Cache), que tiene en cuenta la frescura y la frecuencia, no requiriendo fijar


parámetros de configuración. Aunque queda fuera del alcance de esta exposición el estudio detallado del mismo, a continuación se plantea un bosquejo de su modo de operación:

• Usa dos listas LRU: una de frescura, L1, que incluye las páginas a las que se ha accedido sólo una vez recientemente, y otra de frecuencia, L2, que incorpora aquellas páginas a las que se ha accedido al menos dos veces recientemente.

• Estas listas almacenan información histórica. No sólo guardan el orden LRU de las N páginas resi-dentes en memoria, sino también de otras N páginas adicionales, que corresponden a las últimas Npáginas expulsadas.

• Existe un parámetro de configuración p, que se ajusta automáticamente, y que determina qué tamaño debe tener la lista L1.

• El algoritmo de reemplazo selecciona una página de la lista L1 sólo si su tamaño es mayor que p. En caso contrario, se elige una página de la lista L2. En ambos casos, la selección se realiza mediante LRU y la página expulsada pasa a formar parte del histórico de esa lista.

• El parámetro p se ajusta automáticamente mediante el uso de la información histórica. Si se produce un fallo de página que corresponde a una página del histórico de la lista L1, se incrementa p, puesto que esto indica que el programa está entrando en una fase donde es más importante la frescura (nóte-se que si p=N, se convierte directamente en el algoritmo LRU). En caso de que corresponda al histó-rico de L2, se disminuye el valor de p, dado que esto denota que el programa ha entrado en una fase donde la frecuencia toma mayor importancia.

De forma análoga a lo que ocurre con el algoritmo LRU, la implementación exacta del ARC en un sis-tema de memoria virtual requeriría un hardware específico muy complejo y, posiblemente, ineficiente. Por ello, se han planteado versiones aproximadas del mismo, que pueden implementarse sobre un hardware de gestión de memoria estándar. Entre ellas, se encuentra el algoritmo CAR (Clock with Adaptive Replace-ment), que, como su nombre indica, se basa en una extensión del algoritmo del reloj para que se ajuste a un comportamiento similar al algoritmo ARC.

Buffering de páginasSe puede considerar que el algoritmo de reemplazo también se activa bajo demanda: en el momento que no queda más memoria libre, hay que expulsar alguna página. Sin embargo, esperar a que se llegue a una situa-ción tan crítica de falta total de memoria no parece una buena estrategia, más aún, teniendo en cuenta que si se necesita reservar memoria dentro del contexto de una rutina de interrupción, no se puede bloquear la eje-cución de la misma hasta que no se habilite memoria libre. Para incidir más en la problemática de llegar a ese momento extremo, imagine qué ocurriría si se necesitase reservar memoria durante la propia operación de reemplazo para, por ejemplo, llevar a cabo la escritura en disco. Al no haber memoria libre, no podría com-pletarse la misma, quedando el sistema en un interbloqueo.

Teniendo en cuenta estas consideraciones, la mayoría de los sistemas operativos mantienen una reserva mínima de marcos libres y realizan las operaciones de reemplazo de forma anticipada, fuera del contexto del tratamiento del fallo de página, sin esperar a que se llegue a la situación crítica de agotamiento de la memo-ria. Esta estrategia suele denominarse buffering de páginas. Cuando se produce un fallo de página, se usa un marco de página libre, pero no se aplica el algoritmo de reemplazo. Esto es, se consume un marco de página, pero no se libera otro. Cuando el sistema operativo detecta que el número de marcos de página disminuye por debajo de un cierto umbral, aplica repetidamente el algoritmo de reemplazo hasta que el número de marcos libres llegue a otro umbral que corresponda a una situación de estabilidad. Para realizar esta operación, dado que se requiere un flujo de ejecución independiente dentro del sistema operativo, habitualmente, se usa un proceso/thread de núcleo, que se suele denominar demonio de paginación. Hay que resaltar que debido a la complejidad de la gestión de memoria, ésta suele requerir la presencia de diversos procesos de núcleo (por ejemplo, procesos que escriben páginas modificadas a disco o procesos que rellenan de ceros marcos libres para tenerlos preparados para volver a utilizarlos).

Según el demonio de paginación va aplicando repetidamente el algoritmo, las páginas liberadas que no están modificadas pasan a una lista de marcos libres, estando listas para poder utilizarse de nuevo, mientras


que las páginas que han sido modificadas pasan a una lista de marcos modificados y deberán actualizarse en memoria secundaria antes de poder volver a utilizarse.

Las páginas que están en cualquiera de las dos listas pueden recuperarse si se vuelve a acceder a las mismas antes de reutilizarse. En este caso, la rutina de fallo de página recupera la página directamente de la lista y actualiza la entrada correspondiente de la tabla de páginas para conectarla. Este fallo de página no im-plicaría operaciones de entrada/salida.

Las páginas en la lista de modificadas se pueden escribir en tandas al dispositivo para obtener un mejor rendimiento. Cuando la página modificada se ha escrito al dispositivo, se la incluye en la lista de marcos li-bres.

Esta estrategia puede mejorar el rendimiento de algoritmos de reemplazo que no sean muy efectivos. Así, si el algoritmo de reemplazo decide revocar una página que en realidad está siendo usada por un proce-so, se producirá inmediatamente un fallo de página que la recuperará de las listas.

Este proceso de recuperación de la página plantea un reto: ¿cómo detectar de forma eficiente si la pági-na requerida por un fallo de página está en una de estas listas? La solución es la caché de páginas.

Caché de páginasCon el uso de la técnica de memoria virtual, la memoria principal se convierte, a todos los efectos, en una caché de la memoria secundaria. Por otra parte, en diversas circunstancias, el sistema operativo debe buscar si una determinada página está residente en memoria (esa necesidad se acaba de identificar dentro de la técnica del buffering de páginas y volverá a aparecer cuando se estudie el compartimiento de páginas). Por tanto, parece lógico que ese comportamiento de caché se implemente como tal, es decir, que se habilite una estructura de información, la caché de páginas, que permita gestionar las páginas de los procesos que están residentes en memoria y pueda proporcionar una manera eficiente de buscar una determinada página.

La organización de la caché se realiza de manera que se pueda buscar eficientemente una página dado un identificador único de la misma. Generalmente, este identificador corresponde al número de bloque dentro del fichero (o dispositivo de swap) que contiene la página. Obsérvese que las páginas anónimas que todavía no están vinculadas con el swap no están incluidas en la caché de páginas. Cada vez que dentro de la rutina del tratamiento del fallo de página se copia una página de un bloque de un fichero o de un dispositivo de swap a un marco, se incluirá en la caché asociándola con dicho bloque.

Hay que resaltar que las páginas de la caché están incluidas, además, en otras listas, tales como las ges-tionadas por el algoritmo de reemplazo o la de marcos libres y modificados.

En el sistema de ficheros, como se analizará en el capítulo dedicado al mismo, existe también una caché de similares características, que se suele denominar caché de bloques. Aunque el estudio de la misma se rea-liza en dicho capítulo, se puede anticipar que, en los sistemas operativos actuales, la tendencia es fusionar ambas cachés para evitar los problemas de coherencia y de mal aprovechamiento de la memoria, debido a la duplicidad de la información en las cachés.

Retención de páginas en memoriaPara acabar esta sección en la que se han presentado diversos algoritmos de reemplazo, hay que resaltar que no todas las páginas residentes en memoria son candidatas al reemplazo. Se puede considerar que algunas páginas están atornilladas a la memoria principal.

En primer lugar, están las páginas del propio sistema operativo. La mayoría de los sistemas operativos tienen su mapa de memoria fijo en memoria principal. El diseño de un sistema operativo en el que las páginas de su propio mapa pudieran expulsarse a memoria secundaria resultaría complejo y, posiblemente, ineficien-te. Tenga en cuenta, además, que el código de la rutina de tratamiento del fallo de página, así como los datos y otras partes de código usados desde la misma, deben siempre estar residentes para evitar el interbloqueo. Lo que sí proporcionan algunos sistemas operativos es la posibilidad de que un componente del propio siste-ma operativo reserve una zona de memoria que pueda ser expulsada, lo que le permite usar grandes cantida-des de datos sin afectar directamente a la cantidad de memoria disponible en el sistema.

Además, si se permite que los dispositivos de entrada/salida que usan DMA realicen transferencias di-rectas a la memoria de un proceso, será necesario marcar las páginas implicadas como no reemplazables has-ta que termine la operación.


Por último, algunos sistemas operativos ofrecen servicios a las aplicaciones que les permiten solicitar que una o más páginas de su mapa queden retenidas en memoria (en UNIX existe el servicio mlock para este fin). Este servicio puede ser útil para procesos de tiempo real que necesitan evitar que se produzcan fa-llos de página imprevistos. Sin embargo, el uso indiscriminado de este servicio puede afectar gravemente al rendimiento del sistema.

5.5.9. Política de reparto de espacio entre los procesos

En un sistema con multiprogramación existen varios procesos activos simultáneamente que comparten la memoria del sistema. Es necesario, por tanto, determinar cuántos marcos de página se asignan a cada proce-so. Existen dos tipos de estrategias de asignación: asignación fija o asignación dinámica.

Asignación fijaCon esta estrategia, se asigna a cada proceso un número fijo de marcos de página. Normalmente, este tipo de asignación lleva asociada una estrategia de reemplazo local. El número de marcos asignados no varía, ya que un proceso sólo usa para reemplazo los marcos que tiene asignados.

La principal desventaja de esta alternativa es que no se adapta a las diferentes necesidades de memoria de un proceso a lo largo de su ejecución. Habrá fases en la que el espacio asignado se le quedará pequeño, no permitiendo almacenar simultáneamente todas las páginas que está utilizando el proceso en ese intervalo de tiempo. En contraste, existirán fases en las que el proceso no usará realmente los marcos que tiene asignados. Una propiedad positiva de esta estrategia es que el comportamiento del proceso es relativamente predecible, puesto que siempre que se ejecute con los mismos parámetros va a provocar los mismos fallos de página.

Existen diferentes criterios para repartir los marcos de las páginas entre los procesos existentes. Puede depender de múltiples factores tales como el tamaño del proceso o su prioridad. Por otra parte, cuando se usa una estrategia de asignación fija, el sistema operativo decide cuál es el número máximo de marcos asignados al proceso. Sin embargo, la arquitectura de la máquina establece el número mínimo de marcos que deben asignarse a un proceso. Por ejemplo, si la ejecución de una única instrucción puede generar cuatro fallos de página y el sistema operativo asigna tres marcos de página a un proceso que incluya esta instrucción, el pro-ceso podría no terminar de ejecutarla. Por tanto, el número mínimo de marcos de página para una arquitectu-ra quedará fijado por la instrucción que pueda generar el máximo número de fallos de página.

Asignación dinámicaUsando esta estrategia, el número de marcos asignados a un proceso varía según las necesidades que tenga el mismo (y posiblemente el resto de procesos del sistema) en diferentes instantes de tiempo. Con este tipo de asignación se pueden usar estrategias de reemplazo locales y globales.

• Con reemplazo local, el proceso va aumentando o disminuyendo su conjunto residente dependiendo de sus necesidades en las distintas fases de ejecución del programa.

• Con reemplazo global, los procesos compiten en el uso de memoria quitándose entre sí las páginas. La estrategia de reemplazo global hace que el comportamiento del proceso en tiempo de ejecución no

sea predecible. El principal problema de este tipo asignación es que la tasa de fallos de página de un progra-ma puede depender de las características de los otros procesos que estén activos en el sistema.

HiperpaginaciónSi el número de marcos de página asignados a un proceso no es suficiente para almacenar las páginas a las que hace referencia frecuentemente, se producirá un número elevado de fallos de página. Esta situación se denomina hiperpaginación (thrashing). Cuando se produce la hiperpaginación, el proceso pasa más tiempo en la cola de servicio del dispositivo de swap que en ejecución. Dependiendo del tipo de asignación usado, este problema puede afectar a procesos individuales o a todo el sistema.


En un sistema operativo que utiliza una estrategia de asignación fija, si el número de marcos asignados al proceso no es suficiente para albergar su conjunto de trabajo en una determinada fase de su ejecución, se producirá hiperpaginación en ese proceso, lo que causará un aumento considerable de su tiempo de ejecu-ción. Sin embargo, el resto de los procesos del sistema no se verán afectados directamente.

Con una estrategia de asignación dinámica, el número de marcos asignados a un proceso se va adaptan-do a sus necesidades, por lo que, en principio, no debería presentarse este problema. No obstante, si el núme-ro de marcos de página en el sistema no es suficiente para almacenar los conjuntos de trabajo de todos los procesos, se producirán fallos de página frecuentes y, por tanto, el sistema sufrirá hiperpaginación. La utili-zación del procesador disminuirá, puesto que el tiempo que dedica al tratamiento de los fallos de página au-menta. Como se puede observar en la figura 5.73, no se trata de una disminución progresiva, sino drástica, que se debe a que al aumentar el número de procesos, por un lado, crece la tasa de fallos de página de cada proceso (hay menos marcos de página por proceso) y, por otro lado, aumenta el tiempo de servicio del dispo-sitivo de paginación (crece la longitud de la cola de servicio del dispositivo).

Cuando se produce esta situación se deben suspender uno o varios procesos liberando sus páginas. Es necesario establecer una estrategia de control de carga que ajuste el grado de multiprogramación en el siste-ma para evitar que se produzca hiperpaginación. Este mecanismo de suspensión tiene similitudes con la técnica del intercambio y, como en dicha técnica, habrá que establecer algún tipo de criterio para decidir qué procesos se deberían suspender (criterios tales como si el proceso está bloqueado, su prioridad, el número de páginas residentes, el tamaño de su mapa de memoria o el tiempo que lleva ejecutando). La reactivación de los procesos seleccionados sólo se realizará cuando haya suficientes marcos de página libres. La estrategia que decide cuándo suspender un proceso y cuándo reactivarlo se corresponde con la planificación a medio plazo presentada en el capítulo 4. A continuación, se plantean algunas políticas de control de carga.

Estrategia del conjunto de trabajoComo se comentó previamente, cuando un proceso tiene residente en memoria su conjunto de trabajo, se produce una baja tasa de fallos de página. Una posible estrategia consiste en determinar los conjuntos de tra-bajo de todos los procesos activos para intentar mantenerlos residentes en memoria principal.

Para poder determinar el conjunto de trabajo de un proceso es necesario dar una definición más formal de este término. El conjunto de trabajo de un proceso es el conjunto de páginas a las que ha accedido un pro-ceso en las últimas n referencias. El número n se denomina la ventana del conjunto de trabajo. El valor de nes un factor crítico para el funcionamiento efectivo de esta estrategia. Si es demasiado grande, la ventana podría englobar varias fases de ejecución del proceso, llevando a una estimación excesiva de las necesidades del proceso. Si es demasiado pequeño, la ventana podría no englobar la situación actual del proceso, con lo que se generarían demasiados fallos de página.

Suponiendo que el sistema operativo es capaz de detectar cuál es el conjunto de trabajo de cada proce-so, se puede especificar una estrategia de asignación dinámica con reemplazo local y control de carga.

Grado de multiprogramación

Util

izac

ión

de la

UC

P

Figura 5.73 Hiperpaginación.


• Si el conjunto de trabajo de un proceso decrece, se liberan los marcos asociados a las páginas que ya no están en el conjunto de trabajo.

• Si el conjunto de trabajo de un proceso crece, se asignan marcos para que puedan contener las nue-vas páginas que han entrado a formar parte del conjunto de trabajo. Si no hay marcos libres, hay que realizar un control de carga, suspendiendo uno o más procesos y liberando sus páginas.

El problema de esta estrategia es cómo poder detectar cuál es el conjunto de trabajo de cada proceso. Al igual que ocurre con el algoritmo LRU, se necesitaría una MMU específica que fuera controlando las páginas a las que ha ido accediendo cada proceso durante las últimas n referencias.

Estrategia de administración basada en la frecuencia de fallos de páginaEsta estrategia busca una solución más directa al problema de la hiperpaginación. Se basa en controlar la fre-cuencia de fallos de página de cada proceso. Como se ve en la figura 5.74, se establecen una cuota superior y otra inferior de la frecuencia de fallos de página de un proceso. Basándose en esa idea, a continuación se des-cribe una estrategia de asignación dinámica con reemplazo local y control de carga.

• Si la frecuencia de fallos de un proceso supera el límite superior, se asignan marcos de página adi-cionales al proceso. Si la tasa de fallos crece por encima del límite y no hay marcos libres, se sus-pende algún proceso liberando sus páginas.

• Cuando el valor de la tasa de fallos es menor que el límite inferior, se liberan marcos asignados al proceso seleccionándolos mediante un algoritmo de reemplazo.

Estrategia de control de carga para algoritmos de reemplazo globalesLos algoritmos de reemplazo globales no controlan la hiperpaginación. Incluso aunque se pudiera utilizar el algoritmo óptimo, el problema persistiría, puesto que dicho algoritmo seleccionaría la página menos útil, pe-ro, en estas circunstancias, esa página también es útil. Necesitan trabajar conjuntamente con un algoritmo de control de carga. Normalmente, se usan soluciones de carácter empírico, que detectan síntomas de que el sistema está evolucionando hacia la hiperpaginación. Así, si la tasa de paginación en el sistema es demasiado alta y el número de marcos libres está frecuentemente por debajo del umbral mínimo, se considera que el sistema está en estado de hiperpaginación y se suspende uno o más procesos.

5.5.10. Gestión del espacio de swap

Un dispositivo de swap se implementa sobre una unidad de disco o una partición de la misma. Normalmente, los sistemas operativos ofrecen la posibilidad de utilizar múltiples dispositivos de swap, permitiendo, incluso, añadir dispositivos de swap dinámicamente, e incluso usar ficheros como soporte del swap. Sin embargo, hay

número de marcos

tasa

de

fallo

s de

pág

ina

límite superior

límite inferior

Figura 5.74 Estrategia de administración basada en la frecuencia de fallos de página.


que tener en cuenta que el acceso a los ficheros es más lento que el acceso directo a los dispositivos. En cual-quier caso, esta posibilidad es interesante, ya que alivia al administrador de la responsabilidad de configurar correctamente a priori el dispositivo de swap, puesto que si hay necesidad, se puede añadir más espacio de swap en tiempo de ejecución. Habitualmente, también es posible que el administrador defina el modo de uso de los dispositivos de swap, pudiendo establecer políticas tales como no usar un dispositivo hasta que los otros estén llenos, o repartir cíclicamente las páginas expulsadas entre los dispositivos de swap existentes.

La estructura interna de un dispositivo de swap es muy sencilla: una cabecera y un conjunto de bloques. La cabecera incluye algún tipo de información de control, como, por ejemplo, si hay sectores de disco erró-neos dentro de la misma. No es necesario que incluya información del estado de los bloques, puesto que el dispositivo de swap sólo se usa mientras el sistema está arrancado. Por tanto, no hay que mantener ninguna información cuando el sistema se apaga. El sistema operativo usa un mapa de bits en memoria para conocer si está libre u ocupado cada bloque del swap.

El sistema operativo debe gestionar el espacio de swap reservando y liberando zonas del mismo según evolucione el sistema. Existen básicamente dos alternativas a la hora de asignar espacio de swap durante la creación de una nueva región:

• Con preasignación de swap. Cuando se crea una región privada o sin soporte, se reserva espacio de swap para la misma. Con esta estrategia, cuando se expulsa una página ya tiene reservado espacio en swap para almacenar su contenido. En algunos sistemas, más que realizar una reserva explícita de bloques de swap, se lleva una cuenta de cuántos hay disponibles, de manera que al crear una región que requiera el uso del swap, se descuenta la cantidad correspondiente al tamaño de la misma del to-tal de espacio de swap disponible.

• Sin preasignación de swap. Cuando se crea una región, no se hace ninguna reserva en el swap. Sólo se reserva espacio en el swap para una página cuando es expulsada por primera vez.

La primera estrategia conlleva un peor aprovechamiento de la memoria secundaria, puesto que toda página debe tener reservado espacio en ella. Sin embargo, la preasignación presenta la ventaja de que con ella se detecta anticipadamente si no queda espacio en swap. Si al crear un proceso no hay espacio en swap, éste no se crea. Con un esquema sin preasignación, esta situación se detecta cuando se va a expulsar una página y no hay sitio para ella. En ese momento habría que abortar el proceso aunque ya hubiera realizado parte de su labor.

Como se explicó en la sección 5.5.4, sólo las páginas de las regiones privadas o sin soporte usan el swap para almacenarse cuando son expulsadas estando modificadas. En el caso de una página de una región compartida con soporte en un fichero, no se usa espacio de swap para almacenarla, sino que se utiliza direc-tamente el fichero que la contiene como almacenamiento secundario.

Dado que puede haber múltiples entradas de tablas de páginas que hacen referencia al mismo bloque de swap, el sistema operativo gestionará un contador de referencias por cada bloque de swap, de manera que cuando el mismo valga cero, el bloque estará libre.

5.5.11. Compartimiento de páginas

Como se ha comentado a lo largo del capítulo, los procesos comparten regiones en diversas circunstancias: • Cuando usan explícitamente una zona de memoria compartida. • Cuando utilizan el mismo programa o biblioteca dinámica, comparten implícitamente su código, op-

timizándose de esta forma el uso de recursos en el sistema. • Cuando proyectan un mismo fichero. • En UNIX, cuando un proceso crea un hijo mediante el servicio fork, el proceso hijo comparte con

el padre aquellas regiones de tipo compartido que tenga éste. El compartimiento de las regiones implica, evidentemente, compartir las páginas de la región. Como se

analizó en la sección dedicada a la paginación, para ello, basta con que las entradas correspondientes de las tablas de páginas de los procesos involucrados hagan referencia al mismo marco. En la tabla de marcos, se


almacenará un contador de referencias que indicará cuántas entradas de tablas de páginas hacen referencia a ese marco, de manera que cuando el mismo valga cero, el marco estará libre. En principio, dado que la me-moria virtual se basa en la paginación, la técnica de compartimiento será la misma. Sin embargo, aparecen dos dificultades añadidas:

• Cuando la página compartida no está residente en memoria y uno de los procesos accede a la misma provocando un fallo que la trae a memoria, si otro proceso quiere acceder a la página, deberá usar la copia presente en memoria. La pregunta es cómo descubre ese proceso que la página está residente en memoria. La respuesta es consultando la caché de páginas dentro la rutina de tratamiento del fallo de página. Al encontrar la página en la caché, no es preciso leerla de memoria secundaria y sólo hay que hacer que la entrada de la tabla de páginas haga referencia al marco que la contiene.

• Si el algoritmo de reemplazo decide expulsar una página compartida, habrá que invalidar todas las referencias a ese marco en todas las entradas de las tablas de páginas que la comparten. Esto requiere guardar información que permita realizar la traducción inversa a la que se usa normalmente: dado un marco, se requiere conocer qué entradas hacen referencia al mismo. La gestión de esta información puede causar una sobrecarga apreciable en tiempo y espacio, por lo que algunos sistemas operativos no la proporcionan y sólo pueden expulsar páginas no compartidas. En Linux se utiliza una técnica denominada rmap para gestionar la información necesaria para la traducción inversa, pero intentando minimizar esta sobrecarga.

Además del compartimiento propiamente dicho, existe otro tipo de situaciones en las que se comparte información, aunque sea inicialmente. Se trata de situaciones en las que dos o más procesos usan una región cuyo contenido inicial es el mismo, pero tal que cada uno debe trabajar de forma independiente, de manera que las modificaciones que realice un proceso no sean visibles por el resto.

Este modo de trabajo corresponde con la operación duplicar_región, y puede requerirse en distintas cir-cunstancias:

• Cuando utilizan el mismo programa o biblioteca dinámica, inicialmente, los procesos comparten de forma implícita su región de datos con valor inicial.

• En UNIX, cuando un proceso crea un hijo mediante el servicio fork, inicialmente, el proceso hijo comparte con el padre aquellas regiones de tipo privado que tenga éste.

• Cuando dos o más procesos proyectan un mismo fichero, pero en modo privado. De la misma manera que la paginación por demanda retarda la carga de una página desde la memoria

secundaria hasta que realmente se accede a la misma, se puede plantear realizar un duplicado por demanda, es decir, diferir la copia de cada página de la región hasta que el proceso la intente modificar. Esta técnica se denomina copy-on-write (COW).

Con esta técnica, en vez de copiar la región original, se comparte, pero marcándola de tipo COW. Mientras los procesos que usan esta región sólo la lean pueden seguir compartiéndola. Pero cuando un proce-so intenta modificar una página de esta región, el sistema operativo se encarga de crear una copia privada de la página para ese proceso.

Habitualmente, para forzar la activación del sistema operativo, se modifica la protección de la página en la entrada correspondiente para que sea sólo de lectura, produciéndose una excepción de fallo de protec-ción, en cuyo tratamiento se realiza la copia. No obstante, en la tabla de regiones se sigue manteniendo la protección real de la región.

Tratamiento de la excepción de COWLas dos excepciones que regulan el comportamiento del sistema de memoria virtual son la del fallo de pági-na, que permite implementar la paginación por demanda y que ya se ha estudiado anteriormente, y la del fallo de protección, que permite implementar la técnica del COW. A continuación, se especifican los pasos habi-tuales en el tratamiento de un fallo de protección:

• La MMU produce una excepción, dejando, habitualmente, en un registro especial la dirección que provocó el fallo.


• Se activa el sistema operativo que busca en la tabla de regiones a qué región pertenece la dirección que produjo el fallo, verificando si realmente se trata de un fallo de tipo COW. Para ello, comprueba la protección de la región. Si no tiene permiso de escritura, se trata de un acceso inválido, por lo que se aborta el proceso o se le envía una señal. En caso contrario, se realizan los pasos que se describen a continuación.

• Si el contador de referencias del marco es mayor que 1 (varios procesos todavía comparten la pági-na), se realizan las siguientes acciones:

⎯ Se reserva un marco libre (gracias al buffering de páginas siempre lo habrá). ⎯ Se copia el contenido de la página. ⎯ Se asocia la entrada de la tabla de páginas con este nuevo marco y se le devuelve el permiso

de escritura. ⎯ Se resta una unidad al contador de referencias del marco. La nueva página no se incluye en la

caché de páginas, puesto que, por el momento, no está vinculada con ningún soporte. • Si el contador de referencias del marco ya es igual a 1 (es el único proceso asociado a ese marco),

sólo hay que devolver los permisos a la página, que quedará asignada únicamente a este proceso. Asimismo, hay que eliminar la página de la caché de páginas, rompiendo con ello su vinculación con el soporte actual de la misma (no queremos que un fallo de página de otro proceso que compartía es-ta página la encuentre en la caché de páginas y la utilice, puesto que se trata de una nueva copia).

• Si la página ya tenía un bloque de swap asignado, hay que romper también esta asociación, restando una unidad al contador de referencias del bloque de swap, puesto que ya no está asociado a la página asignada al proceso como resultado del COW. Cuando se expulse la página, se le asignará un nuevo bloque de swap.

5.5.12. Gestión de la memoria del sistema operativo

En esta sección se analiza cómo se lleva a cabo la gestión de memoria desde el punto de vista del sistema operativo, mostrando cómo gestiona la memoria física, así como su mapa de memoria lógico. Asimismo, se revisarán los distintos esquemas de asignación de espacio proporcionados por el sistema operativo.

Gestión de la memoria físicaEn su fase de iniciación, el sistema operativo recibe información (normalmente, invocando alguna rutina del firmware) sobre las características de la memoria física disponible. A priori, puede parecer que es suficiente con que sepa cuánta memoria existe. Sin embargo, las cosas son bastante más complejas y necesita conocer mucha más información, puesto que la memoria física no es algo uniforme o contiguo. Puede haber huecos en el espacio de direcciones de la memoria y zonas de memoria ROM. Además, puede haber restricciones en el uso de ciertas partes de la memoria. Por ejemplo, en algunos sistemas, por limitaciones del hardware, sólo se puede hacer DMA sobre determinadas zonas de la memoria, de lo cual debe ser consciente el sistema ope-rativo a la hora de asignar espacio (en Linux, se utiliza el concepto de zona para gestionar este tipo de restric-ciones). Asimismo, si se trata de un sistema multiprocesador NUMA, será necesario que el sistema operativo conozca la topología del sistema, de manera que cuando un proceso necesite memoria, se le pueda asignar de la parte asociada al procesador donde está ejecutando (en Linux, se usa el concepto de nodo para implemen-tar esta característica).

Una vez que el sistema operativo averigua las características de la memoria disponible en el sistema, crea una tabla de marcos del tamaño adecuado e inicia las entradas de la misma, de manera que los marcos donde está ubicado el sistema operativo se ponen como ocupados y los restantes como libres.

Gestión del mapa de memoria del sistema operativoEl sistema operativo posee su propio mapa de memoria definido por la tabla de páginas del sistema. En el arranque del sistema, el hardware de gestión de memoria estará desactivado. En su fase de iniciación, el sis-


tema operativo construirá su tabla de páginas y activará el hardware de gestión de memoria. Normalmente, en el proceso de arranque del computador, se carga el sistema operativo en una zona contigua de la memoria física. Por tanto, se iniciarán las primeras entradas de la tabla de páginas del sistema de manera que hagan referencia a esos marcos contiguos que ocupa inicialmente el sistema operativo, creando un espacio lógico para el mismo. Gracias a esa contigüidad, se pueden usar superpáginas para dar cobertura al espacio ocupado por el sistema operativo, lo que minimiza el número de entradas requeridas. Las entradas restantes de la tabla de páginas del sistema se quedarán sin usar (marcadas como inválidas).

Una vez terminada la fase de iniciación, todos los marcos libres disponibles quedan a disposición de los procesos y de las necesidades internas del propio sistema operativo (cachés, memoria dinámica, etc.). Cuando el sistema operativo quiera usar un marco de página libre, deberá crear una asociación al mismo, iniciando una entrada de la tabla de páginas del sistema que esté sin usar, de forma que haga referencia a ese marco. Si se trata de una página para un proceso, se producirá una asociación temporal mientras el sistema operativo carga el contenido de la página, que desaparecerá cuando la página se asigne al proceso incluyéndola en su tabla de páginas. En caso de que la página sea para el propio sistema operativo (por ejemplo, para reservar dinámicamente espacio para un nuevo BCP), se establecerá una asociación que se mantendrá hasta que se libere explícitamente ese espacio reservado. Hay que resaltar que cualquier modificación en una entrada de la tabla de páginas del sistema conlleva una cierta sobrecarga, puesto que, como se verá en la próxima sección, requiere operaciones sobre la TLB (además, en el caso de que el procesador no use tablas de usuario y siste-ma independientes, habría una sobrecarga debida a la propagación del cambio a todas las copias de la tabla de páginas del sistema).

Algunos sistemas operativos usan una solución alternativa: incluyen toda la memoria física en el espa-cio del sistema. En vez de crear un mapa inicial del sistema que incluya sólo las regiones del sistema operati-vo y usar asociaciones para acceder al resto de la memoria, como se acaba de explicar, establecen un mapa del sistema que cubre toda la memoria física: la primera página del mapa del sistema operativo se hace co-rresponder con el primer marco, la segunda con el segundo, y así sucesivamente. Esta solución, usada en Li-nux, permite que el sistema operativo manipule directamente toda la memoria física, sin necesidad de realizar asociaciones. Esta solución elimina la sobrecarga asociada a los cambios en la tabla de páginas del sistema y permite usar superpáginas para representar toda la memoria física. En este tipo de sistemas es inmediato el cálculo de a qué dirección física corresponde una dirección lógica del sistema: basta con restar el valor de la primera dirección lógica del sistema (en una configuración con 3GB de usuario y 1GB de sistema, la primera dirección lógica de sistema es C0000000, que es el valor que hay que restar a una dirección lógica de sistema para obtener la dirección física que representa). Las entradas restantes de la tabla de páginas del sistema se usan para poder asignar espacio lógico contiguo usando espacio físico que no lo es.

Esta solución tiene la limitación de que sólo se puede manejar tanta memoria física como tamaño tenga el espacio lógico del sistema (si hay un espacio lógico de 1GB, sólo se puede gestionar directamente esa can-tidad de memoria física, que es claramente insuficiente actualmente). Por ello, en este tipo de sistemas suele ser habitual una mezcla de las dos técnicas, es decir, establecer un mapa de sistema que cubra toda la memo-ria física posible, dejando una cantidad suficiente de entradas de la tabla de páginas de sistema sin usar para manejar el resto de la memoria (denominada en Linux high memory) mediante asociaciones.

Esquemas de asignación de espacioAntes de presentar los diversos tipos esquemas de asignación de memoria que proporciona habitualmente el sistema operativo para su uso interno, es conveniente comparar dos soluciones a la hora de satisfacer una solicitud de memoria de algún componente del sistema operativo que necesita una zona contigua que ocupe varias páginas:

• Una alternativa es reservar un conjunto de marcos cualesquiera, aunque no sean contiguos, y crear entradas en la tabla de páginas del sistema para que aparezcan como contiguos en el espacio lógico.

• La otra opción es reservar un conjunto contiguo de marcos. Esta puede ser la única opción posible si el espacio se necesita para realizar una operación de DMA sobre el mismo. Además, en caso de usar un sistema que incluya la memoria física dentro del mapa del sistema, como Linux, la operación es más eficiente, ya que no requiere manipular la tabla de páginas para establecer asociaciones.


Habitualmente, el sistema operativo ofrece distintos tipos de gestores de memoria internos, que intentan adaptarse a las diversas necesidades del propio sistema operativo y de los procesos.

• En ocasiones, el sistema operativo necesita reservar una o más páginas contiguas en memoria en el espacio físico. Un manejador de un dispositivo puede necesitar reservar un buffer de varias páginas como almacenamiento intermedio de datos del dispositivo. Otro ejemplo aparece en el tratamiento de un fallo de página, donde el sistema operativo necesita reservar una página para el proceso. Linux utiliza un sistema buddy binario para gestionar los marcos libres, con tamaños que van desde 1 pági-na hasta 1024 páginas, y ofrece un conjunto de operaciones para reservar marcos de página, con fun-ciones tales como get_free_pages.

• El código del sistema operativo puede necesitar reservar memoria dinámica igual que cualquier apli-cación. De hecho, para que no quepa duda de la similitud, en Linux la función interna se llama kma-lloc. En Linux, este componente de reserva dinámica se construye directamente sobre el sistema de asignación de páginas explicado en el punto anterior, y usa un esquema de múltiples listas con particiones estáticas cuyos tamaños son potencias de 2, desde 32 bytes hasta 128KB. Este subsistema funciona como una caché. Cuando se realiza una petición y no hay espacio libre asociado a este sub-sistema, se solicitan páginas al sistema de asignación de páginas. Sin embargo, cuando se libera, no se devuelve al sistema de asignación de páginas.

• El código del sistema operativo requiere frecuentemente reservar y liberar objetos del mismo tipo (por ejemplo, espacio para un BCP). Para agilizar esta labor, el sistema operativo permite crear cachés específicas para cada tipo de objeto. De esta forma, para crear un nuevo BCP se puede usar directamente uno disponible en la caché, eliminando la necesidad de la reserva. En Linux se usa el gestor de slabs para este fin, construyéndose también sobre el sistema de asignación de páginas.

• Por último, como ya se comentó antes, se ofrecen funciones para reservar memoria contigua en el espacio lógico, aunque no contigua en el físico. En Linux, se usa la función vmalloc para tal fin.

En algunos sistemas operativos toda la memoria del sistema está residente en memoria física. Sin em-bargo, otros sistemas operativos, como Windows, permiten reservar memoria que puede ser expulsada (me-moria que puede ser paginada al disco). Esta opción puede ser interesante para un módulo del sistema operativo que requiera usar una gran cantidad de memoria, pero no de forma simultánea. Téngase en cuenta que, a excepción de esta modalidad de reserva de memoria que puede ser paginada, en todos los demás casos cada byte de memoria que utiliza cualquier componente del sistema operativo es un byte que deja de estar disponible para los procesos

Como se ha podido apreciar en este apartado, el sistema operativo utiliza numerosas cachés (por ejem-plo, en Linux las correspondientes a los slabs y a las listas de particiones estáticas del kmalloc). Estas cachés van creciendo y, en principio, nunca reducen su tamaño por iniciativa propia. Por tanto, cuando el demonio de paginación se activa para liberar marcos de página, deberá considerar por un lado las páginas de usuario, aplicando el algoritmo de reemplazo correspondiente, y, por otro lado, el espacio libre de las diver-sas cachés. Buscar un equilibrio en el uso de la memoria por parte de estas dos entidades es un asunto com-plejo, que requiere ajustes de carácter empírico.

Un último aspecto a tener en cuenta es que en sistemas multiprocesadores hay que intentar minimizar la congestión en la reserva de memoria reduciendo dentro de lo posible el uso de los cerrojos que se requieren para la manipulación de las estructuras de datos que reflejan el estado de la memoria. Por ello, suele ser habi-tual que las diversas cachés presentes en el sistema tengan una prerreserva de elementos para cada procesa-dor. Mientras haya elementos en la prerreserva de un procesador, se pueden usar en ese procesador sin necesidad de utilizar el cerrojo. En el caso de Linux, hay una prerreserva de marcos de página libre por pro-cesador y una para los slabs.

5.5.13. Coherencia de la jerarquía de memoria

La jerarquía de memoria es un sistema complejo formado por múltiples niveles y componentes, donde se presentan numerosos problemas de coherencia, más aún en el caso de un sistema multiprocesador. Depen-


diendo del tipo de problema y de las características específicas del hardware del sistema, el componente en-cargado de mantener la coherencia puede ser distinto. En algunos casos, será el propio hardware el que re-suelva el problema, pero, en otros, tendrá que ser el sistema operativo.

El objetivo de esta sección es tratar todos estos problemas de una manera integrada, a pesar de su enorme variedad. Para ello, se presenta un modelo general original que permite identificar aquellos aspectos de la jerarquía de memoria que influyen en el mantenimiento de la coherencia en un sistema de estas carac-terísticas. De acuerdo con este modelo, cada nivel en una jerarquía se caracteriza por los siguientes aspectos:

• La función de traducción requerida para, dado un identificador único del objeto que se pretende ac-ceder, encontrar en qué bloque de ese nivel está almacenada, en caso de que esté presente en el mis-mo.

• La necesidad, por motivos de eficiencia, de, a su vez, una jerarquía de niveles en el propio esquema de traducción de un nivel. Este es el caso del mecanismo de traducción del nivel de memoria princi-pal, que requiere el uso de dos niveles de traducción: la TLB y la tabla de páginas.

• La existencia de múltiples componentes de memoria en ese nivel. En un sistema multiprocesador, en el nivel de caché hay múltiples componentes: una caché por cada procesador. También en un sistema uniprocesador pueden existir múltiples componentes en un nivel. Así, en el nivel de caché puede haber una caché de instrucciones y una de datos, cuyos contenidos no son totalmente disjuntos, ya que a las instrucciones también se accede como datos cuando se carga un programa en memoria.

• Las entidades que pueden acceder a ese nivel. A algunos niveles de la jerarquía, además de los pro-cesos, también pueden acceder dispositivos de entrada/salida mediante DMA, tal como se estudiará en el capítulo 8.

• El tipo de multiplexación que se realiza para que un componente pueda almacenar información de varios procesos. Como se vio al principio del capítulo, puede usarse una multiplexación temporal o espacial.

En cuanto a la función de traducción de un nivel, debería recibir un identificador único del objeto que se pretende acceder. Retomando la notación de la sección 5.2.5 y el proceso de transformación de direccio-nes, en un sistema de memoria virtual, no se puede usar la dirección física como identificador único de un objeto, puesto que puede variar a lo largo de la ejecución del programa. Básicamente, se presentan dos op-ciones dependiendo de si se trata de un sistema con un espacio lógico por proceso o global. En el primer ca-so, el identificador estaría formado por una dirección lógica en el contexto de un proceso ([P, Dp]), mientras que en el segundo correspondería con una dirección lógica en un espacio global ([Dg]).

A continuación, se aplica este modelo a los niveles habituales de la jerarquía, de manera ascendente, obviando el nivel de registros para no alargar innecesariamente la exposición. Ese nivel de registros lo ges-tiona directamente el sistema de compilación y no incumbe al sistema operativo, pero, en cualquier caso, se le puede aplicar perfectamente el modelo.

Nivel de memoria secundariaTanto si es un sistema con un espacio lógico por proceso como si es global, la traducción de la dirección lógica al bloque de memoria secundaria que la contiene se llevaría a cabo usando las tablas del esquema de memoria virtual (tablas de páginas y de regiones). Dado que sólo se requiere localizar el bloque en memoria secundaria cuando no está en la principal, no es necesario que este proceso de localización sea especialmente eficiente, no requiriendo, por tanto, una jerarquía de traducción.

Se trata de un nivel formado por un único componente, que realiza una multiplexación espacial para re-partir el espacio entre los procesos.

Nivel de memoria principalSe corresponde también con un nivel formado por un único componente, que lleva a cabo una multiplexación espacial para repartir el espacio entre los procesos (aunque también temporal puesto que a un marco se le asignan distintas páginas a lo largo del tiempo). La traducción en este nivel la realiza la tabla de páginas, que permite encontrar el marco de página que contiene el dato requerido. Dado que esta traducción debe ser ex-tremadamente eficiente, como se explicó previamente, se usa la TLB.


Existe, por tanto, a su vez, una jerarquía de traducción, a cuyos niveles se accede con el mismo identifi-cador, pero para buscar la localización del dato en vez del dato propiamente dicho. Existen, habitualmente, dos niveles: las tablas de páginas y la TLB. Como se comentó previamente, la TLB puede incluir informa-ción de proceso, en cuyo caso realiza una multiplexación espacial del espacio dedicado a almacenar informa-ción de traducciones, o no incluirla, realizando una multiplexación temporal (es decir, no podrá existir información de varios procesos simultáneamente). En el caso de un multiprocesador, el nivel de TLB presen-ta múltiples componentes: una TLB por procesador.

Además del procesador, a este nivel también acceden los dispositivos de E/S basados en DMA. En la mayoría de los sistemas, los dispositivos realizan operaciones de DMA usando direcciones físicas.

Nivel de cachéPara simplificar, sólo se considera un nivel de caché, pero se puede extrapolar a cualquier número de niveles. Se trata de un nivel que está formado por múltiples componentes. En el caso de un sistema multiprocesador, hay una caché por procesador. Incluso en un sistema monoprocesador puede haber múltiples componentes en el mismo nivel si se usa un procesador con caché de datos e instrucciones separadas (tenga en cuenta que no se trata de cachés disjuntas, puesto que una instrucción también es un dato cuando se está cargando en me-moria). No requiere una jerarquía de traducción puesto que la información requerida para la traducción se maneja eficientemente al estar incluida en la propia lógica de control de la caché.

En cuanto a la función de traducción planteada por el modelo, hay dos alternativas que establecen dos arquitecturas diferentes en el diseño de la caché:

• Caché virtual. A este tipo de caché se accede con una dirección lógica, ya sea en el contexto de un proceso ([P, Dp]) o en un espacio global ([Dg]). El acceso a esta caché se realiza en paralelo con el de la memoria principal (con el acceso a la TLB, que comprueba aspectos como los permisos de acceso). La caché puede incluir información de proceso o no (multiplexación espacial o temporal, respectivamente).

• Caché física. A este tipo de caché se accede con una dirección física ([Df]). Dado que en un siste-ma de memoria virtual la dirección física asociada a un objeto puede cambiar, esta caché requiere que se realice primero la etapa de traducción en el nivel de memoria principal (en el mejor de los ca-sos, un acceso a la TLB) antes de poder realizar el acceso a la caché, para poder determinar cuál es la dirección física actual del objeto de memoria requerido. Esto provoca una falta de paralelismo en los accesos a memoria, puesto que no se puede consultar simultáneamente la caché y la TLB. Para paliar este problema, se puede usar una caché tal que el índice de selección que se utiliza para acceder a la misma corresponda con la parte de la dirección lógica que representa el desplazamiento dentro de la página, puesto que este valor sigue siendo el mismo en la dirección física. Con esta estrategia, se puede realizar la etapa de selección del conjunto de la caché que contiene el dato deseado mientras está trabajando la TLB, de manera que cuando termine la TLB, quede sólo por realizar la compara-ción de etiquetas. Esta solución, sin embargo, limita el tamaño máximo de la caché (una caché con correspondencia directa estaría limitada al tamaño de la página; una asociativa por conjuntos con dos líneas de caché por conjunto tendría un tamaño máximo de dos veces el tamaño de la página y, así sucesivamente).

Una vez aplicado el modelo, en los siguientes apartados se analizan los posibles problemas de coheren-cia.

Problemas de coherencia entre niveles adyacentesEste problema surge cuando se produce una actualización de un objeto de memoria en un nivel y hay una lectura de dicho objeto en otro nivel adyacente, no habiéndose propagado la actualización. A continuación, se plantean varias situaciones en las que se presenta este problema.

En primer lugar, consideremos el problema de coherencia entre la caché y la memoria principal si un dispositivo realiza DMA directamente sobre la memoria principal. El problema puede presentarse en ambas direcciones:


• Actualización en el nivel más rápido. Un proceso escribe datos en un buffer y se arranca una ope-ración de DMA. Si la caché no usa write-through, algunos datos pueden no haberse actualizado en memoria principal y, por tanto, la operación de DMA estará leyendo datos incorrectos. En algunos sistemas, este problema lo resuelve directamente el hardware, pero, en otros, debe hacerlo el sistema operativo, forzando que se actualicen en memoria principal todos los datos del buffer.

• Actualización en el nivel más lento. Una vez que se completa una operación de DMA sobre un buf-fer, un proceso puede seguir leyendo datos obsoletos presentes en la caché, puesto que no se han ac-tualizado. Si el hardware no soluciona este problema, cuando concluya la operación de DMA, habrá que invalidar de la caché las direcciones correspondientes a ese buffer.

Además de en la jerarquía de datos, pueden producirse problemas de este tipo en una jerarquía de tra-ducción. Concretamente, existirán problemas de coherencia si se actualiza la información de la tabla de pági-nas (nivel más lento) y se usa información de la TLB ya obsoleta. Este problema atañe exclusivamente al sistema operativo y es labor del mismo resolverlo. Cada vez que el sistema operativo modifique algún campo de una entrada de la tabla de páginas que potencialmente pueda estar incluida en la TLB, debe solicitar la invalidación de dicha entrada en la TLB. Eso incluye cambios en la protección de una página, como sucede con la técnica del COW, cambios en los bits de referencia o de modificado, la invalidación de una página en la tabla de páginas, ya sea debido a que se expulsa o a que deja de ser válida al eliminarse la región que la contiene, etcétera.

Problemas de coherencia entre componentes del mismo nivelEn un multiprocesador existen niveles en los que hay múltiples componentes, uno por procesador. Es preciso asegurar que no se producen problemas de coherencia cuando se realiza una actualización de un dato en un componente y una consulta del mismo en otro componente de ese mismo nivel. Se presentan dos situaciones de este tipo:

• Coherencia entre múltiples cachés. Normalmente, el hardware del multiprocesador resuelve este problema.

• Coherencia entre múltiples TLB. De esta labor se tiene que encargar el sistema operativo. Dado que la TLB es básicamente un componente de consulta, los problemas de coherencia se restringen a cuando se invalida una entrada de la TLB. En un multiprocesador, es necesario invalidar todas las entradas que puedan existir en el sistema correspondientes a esa página. Habitualmente, esta invali-dación se implementa usando IPI (interrupciones entre procesadores): desde el procesador donde se invalida la TLB se envía una IPI a todos los procesadores cuyas TLB puedan contener esa entrada. Dada la sobrecarga de esta operación, algunos sistemas operativos utilizan algoritmos de reemplazo que no actualizan el bit de referencia en su versión para multiprocesadores (poner a 0 el bit de refe-rencia implicar invalidar entradas de las TLB).

Como se comentó anteriormente, en un sistema monoprocesador también pueden aparecer este tipo de problemas si existen cachés de instrucciones y de datos separadas. Cuando se está cargando en memoria el código de un programa, éste pasa a través de la caché de datos. Sin embargo, a la hora de comenzar la ejecu-ción, las instrucciones se leen de las cachés de instrucciones. Algunos procesadores mantienen de forma au-tomática la coherencia de estas cachés. Sin embargo, en otros, debe ser el sistema operativo el encargado de llevarla a cabo. Para ello, después de completarse la carga del programa en memoria, el sistema operativo debe volcar a memoria las entradas de la caché de datos vinculadas con el rango de direcciones donde se ha cargado el código, así como invalidar las entradas de la caché de instrucciones correspondientes a dicho ran-go.

Problemas de coherencia debidos al uso de homónimosUn homónimo se produce cuando un mismo nombre hace referencia a dos objetos diferentes. En el caso de la jerarquía de memoria, esta situación sólo se puede producir en sistemas que usan un espacio lógico por cada proceso, puesto que en ellos una misma dirección lógica se refiere a distintos objetos dependiendo de qué proceso la use. En cualquier caso, los homónimos sólo generan problemas de coherencia en sistemas donde


se realice una multiplexación temporal del componente de memoria, es decir, en aquéllos en los que no se gestiona información de proceso. Eso ocurre en la caché virtual y en la TLB cuando no incluyen información de proceso. El sistema operativo debe encargarse de resolver este problema, invalidando el componente de memoria (la TLB o la caché virtual) en cada cambio de contexto.

Dentro de este apartado también se podría considerar el problema que surge en los accesos por DMA a memoria si el sistema operativo asigna otra página a un marco involucrado en la operación de DMA, que en la mayoría de los procesadores, usa directamente direcciones físicas. Se trata de un problema de homónimos que el sistema operativo resuelve reteniendo en memoria las páginas involucradas, tal como se explicó en la sección 5.5.8.

Problemas de coherencia debidos al uso de sinónimosUn sinónimo se produce cuando dos o más nombres diferentes se refieren al mismo objeto. Esta situación es habitual en un sistema de memoria, puesto que va unida intrínsicamente al compartimiento de información. El problema surge cuando en un determinado nivel no se detecta que dos direcciones lógicas corresponden a un mismo objeto, gestionando dos copias independientes del mismo dato, con los problemas de coherencia asociados. En el nivel de memoria principal este problema queda resuelto mediante la caché de páginas, que asegura que las referencias a una página compartida utilizan el mismo marco. Tampoco se produce en la memoria secundaria, donde se usa un único bloque swap para la página compartida.

En caso de utilizar una caché virtual con información de proceso, sí puede presentarse este problema de duplicidad de memoria en ese nivel, existiendo distintas alternativas para resolverlo:

• El hardware de la caché lo detecta y resuelve automáticamente. • El sistema operativo establece restricciones en el alineamiento de las regiones compartidas (por

ejemplo, que empiecen en una dirección que sea múltiplo de 64KB), asegurando que dos sinónimos ocupan la misma línea de la caché y, por tanto, nunca pueden almacenarse simultáneamente en la memoria caché.

• El sistema operativo se asegura de que cuando ejecuta un proceso, no haya ninguna entrada en la caché asociada a otro proceso que sea un sinónimo de las usadas por el proceso actual, invalidando previamente las entradas conflictivas.

• Se usa un esquema que utiliza un único espacio global, eliminado directamente el problema, puesto que no existen los sinónimos.

5.5.14. Operaciones del nivel de procesos y de regiones

Añadir la técnica de memoria virtual a un esquema de paginación básicamente sólo cambia un aspecto en cuanto a la implementación de las operaciones de estos niveles: toda reserva de memoria del sistema se re-trasa hasta justo el momento en el que se accede a la misma, realizándose en el contexto de la rutina de tra-tamiento del fallo de página o del fallo de protección.

Las operaciones en el nivel de procesos son idénticas a las usadas en un esquema de paginación sin memoria virtual, que se estudiaron en la sección dedicada a este esquema. Las operaciones de regiones, vistas también en esa sección, sólo cambian en el aspecto reseñado en el párrafo anterior. A continuación, se analiza cómo se realizan las diversas operaciones sobre las regiones en un sistema con memoria virtual.

Creación de una regiónToda la gestión correspondiente al nivel de regiones es idéntica a la usada en un sistema de paginación sin memoria virtual. La variación se corresponde con la labor en el nivel de procesos, puesto que, en este caso, cuando se crea una región, no se le asigna memoria principal, dado que se cargará por demanda. Si se usa la técnica de la creación de páginas por demanda, ni siquiera hay que modificar la tabla de páginas.

Si en el sistema hay preasignación de swap y se trata de una región privada o sin soporte, hay que re-servar en el momento de la creación la zona correspondiente del swap. En un sistema sin preasignación, se reservará espacio en swap para una página cuando se expulse por primera vez estando modificada.


En la creación de la imagen inicial del proceso durante la activación de un programa, se crean todas las regiones iniciales siguiendo el procedimiento que se acaba de describir. Por tanto, en un sistema que utilice tablas de páginas multinivel, basta con asignar una tabla del nivel superior con todas las entradas inválidas.

Dado que la memoria virtual gestiona la información usando páginas completas y el sistema de ficheros utiliza bloques completos, la forma natural de asignar los bloques de un fichero ejecutable a las regiones del proceso sería la siguiente:

• El primer bloque (bloque 0) del ejecutable corresponde con la cabecera del ejecutable, que no se car-ga en memoria durante la ejecución del programa.

• A la región de código se le asignará un número entero de bloques en el fichero y un número entero de páginas en el mapa. Si la región ocupa C bloques, se almacenará en los bloques del ejecutable desde el 1 hasta el C.

• La región de datos con valor inicial comienza justo después, ocupando también un número entero de bloques y de páginas.

El problema de esta solución es que dedica un bloque completo a la cabecera, aunque normalmente sólo ocupa un centenar de bytes. Además, asigna más espacio del requerido a la región de código y de datos con valor inicial, al tener que redondear su tamaño a un número entero de bloques. Con esa estrategia, incluso un ejecutable muy pequeño ocuparía tres bloques. Ante esta deficiencia, algunos sistemas operativos usan este esquema alternativo, que optimiza el uso del disco haciendo que toda la información se almacene de forma contigua en el fichero:

• La cabecera y el principio del código comparten el primer bloque del fichero. Por tanto, cuando se carga la primera página del mapa, se trae a memoria también la cabecera, aunque ésta no se necesite.

• La región de código y de datos están dispuestas en el fichero de forma contigua. Por tanto, puede haber un bloque que contenga una primera parte de código y una segunda de datos con valor inicial. Dado que ese bloque debe ser visto a la vez como una página de código, con permiso de lectura y ejecución, y de datos con valor inicial, con permiso de lectura y escritura, habrá dos páginas diferen-tes, contiguas en el mapa, que se corresponderán con ese bloque. Se trata, por tanto, de un objeto compartido por el mismo proceso, pero con distinta protección. Dicho de otra forma, en la tabla de regiones, el último bloque del fichero ejecutable asociado a la región de código es el mismo que el primero de la región de datos con valor inicial. Obsérvese que el proceso sólo accederá a la primera parte de la última página de código y a la segunda parte de la primera página de la región de datos con valor inicial, quedando una zona sin usar en el mapa del proceso del tamaño de una página (aun-que no alineada en memoria).

Esta solución ahorra espacio en disco, presentando únicamente dos aspectos negativos, perfectamente tolerables: la sobrecarga de leer la cabecera del disco y el espacio en memoria que ocupa, a pesar de que su presencia en memoria no sea necesaria, y la pérdida de protección de la última página de código, que puede modificarse por error a través de la primera página de la región de datos sin que se detecte.

El único detalle que falta por aclarar es dónde se crea el contenido inicial de la pila, formado por los ar-gumentos y las variables de entorno que recibe el programa. Las dos opciones habituales son almacenarlo en marcos de página y hacer que la tabla de páginas inicial haga referencia a esos marcos, o bien guardarlo en bloques de swap, indicándolo en las entradas de la tabla de páginas involucradas.

En la figura 5.75 se muestra cómo es la imagen de memoria inicial de un proceso en un sistema donde se usa la segunda opción de implementación de pila planteada. Para simplificar, se ha supuesto que se utiliza una tabla de páginas de un solo nivel. En esta figura se muestra, con zonas sombreadas, cómo la cabecera ocupa una primera parte de la región de código, y cómo la última parte de la segunda página de código y la primera de la de datos con valor inicial no son utilizadas. La tabla de regiones muestra el compartimiento del bloque 1 del fichero por parte de la región de código y la de datos con valor inicial.

Eliminación de una regiónNuevamente, las acciones son iguales que en un sistema de paginación sin memoria virtual. Además, si se trata de una región privada, hay que liberar los bloques de swap asociados a la región.


Cambio del tamaño de una regiónVuelve a ser muy similar a cómo se realiza en un esquema de paginación sin memoria virtual. Con respecto a una disminución de tamaño en una región, si se trata de una región privada, habrá que liberar los bloques de swap asociados a la misma. Por lo que se refiere a un aumento de tamaño, la única diferencia con el sistema sin memoria virtual es que, como en la creación de una región, no hay que asignar marcos ni actualizar la tabla de páginas. Sólo se necesita ajustar el tamaño en la tabla de regiones. Si en el sistema hay preasignación de swap y se trata de una región privada o sin soporte, hay que reservar el espacio requerido en el swap.

El tratamiento de la expansión de la pila es algo más complejo, ya que no proviene de una solicitud del proceso, sino de la propia evolución de la pila. Cuando se produce una expansión de pila, se genera un fallo de página asociado a una dirección que se corresponde con un hueco. El sistema operativo podría pensar, en principio, que se trata de un acceso erróneo, puesto que no corresponde a ninguna región. Para diferenciarlo, debe comparar la dirección que causó el fallo con el puntero de pila. Si la dirección es mayor, está dentro de la pila. Se trata de una expansión de la pila que implica simplemente actualizar la tabla de regiones, reservar espacio de swap si hay preasignación, y servir el fallo de página de manera convencional. En caso contrario, se trata de un acceso erróneo. Tenga en cuenta que si hay un hueco de una sola página entre la pila y la región anterior, no se permitirá la expansión, ya que si se llevara a cabo, la próxima expansión usaría directamente una página de la otra región sin avisar al sistema operativo (este hueco actúa como una página de seguridad).

Duplicado de una regiónEsta operación sí cambia de manera considerable al aplicar en este caso la técnica de copia diferida basada en el COW, tal como se explicó en la sección 5.5.11. Con esta técnica, la operación de duplicado no requiere reservar marcos de página ni realizar una copia del contenido de las páginas de la región. Basta con duplicar las entradas de la tabla de páginas que corresponden con la región, marcándolas como de sólo lectura tanto en la tabla de páginas origen como en la destino. Asimismo, habrá que incrementar los contadores de referencias de los bloques de swap y de los marcos de página asociados a la región.

Con esta técnica, se optimiza considerablemente la ejecución de un servicio fork, ya que sólo es nece-sario duplicar su tabla de páginas, en vez de su mapa. En la figura 5.76 se muestra cómo se llevaría a cabo una operación fork. En ella se puede apreciar como esta operación implica duplicar tanto la tabla de regio-nes como la de páginas. Obsérvese como se ha eliminado el permiso de escritura en la quinta entrada de am-bas tablas de páginas. Para simplificar, se ha supuesto que se utiliza una tabla de páginas de un solo nivel.

08192


BCP

t. de regiones

t. páginas

00000 I 000

Mapa de memoria inicial

Datos con valor inicial

.........

0

8192

16384

MemoriaCódigo

C0000000

8192

16384


......................... ........

Fichero

20480

.........

81928192


163844096


Fichero F

00000 I 000

Fichero

Bloq. 0

.........

Swap (SW1)

Bloq. 1Bloq. 2

.........

Datos sin valor inicial

00000 I 000

00000 I 000

BFFFF000 Pila

00002 I SW100000 I 000................

BFFFF0004096


00000 I 000


Figura 5.75 Estado inicial de ejecución de un programa.


5.5.15. Ficheros proyectados en memoria

La generalización de la técnica de memoria virtual permite ofrecer a los usuarios una forma alternativa de acceder a los ficheros. Como se ha visto en la sección anterior, en un sistema de memoria virtual, se hacen corresponder entradas de la tabla de páginas con bloques del fichero ejecutable. La técnica de proyección de ficheros en memoria plantea usar esa misma idea, pero aplicada a cualquier fichero. El sistema operativo va a permitir que un programa solicite que se haga corresponder una zona de su mapa de memoria con los bloques de un fichero cualquiera, ya sea completo o parte del mismo. En la solicitud, el programa especifica el tipo de protección asociada a la región y si la región será compartida o privada. El sistema operativo simplemente realiza una operación de crear región, tal como se ha explicado en la sección previa.

Una vez que el fichero está proyectado, si el programa accede a una dirección de memoria perteneciente a la región asociada al fichero, estará accediendo al fichero. El programa ya no tiene que usar los servicios del sistema operativo para leer (read) y escribir (write) en el fichero.

La figura 5.77 muestra un ejemplo de una proyección de un fichero de 40.000 bytes. Como se puede apreciar en la misma, existe una entrada en la tabla de regiones que representa la proyección y que almacena las características de la misma; en este caso, es una proyección compartida de lectura y escritura. En el ejem-plo de la figura, si el programa lee un byte de la dirección de memoria 20480, estará leyendo el primer byte del fichero, mientras que si escribe un byte en la dirección 20481, estará escribiendo en el segundo byte del fichero. En la figura, se ha supuesto que ya se ha producido este acceso y, por ello, el primer bloque del fi-chero está residente en el marco 4 de la memoria.

La proyección de un fichero no implica que se le asigne memoria principal. El propio mecanismo de memoria virtual será el que se encargue de ir trayendo a memoria principal los bloques del fichero cuando se produzca un fallo de página al intentar acceder a la región asociada al mismo, y de escribirlos cuando la página sea expulsada estando modificada.

El acceso a un fichero mediante su proyección en memoria presenta numerosas ventajas sobre el acceso convencional basado en los servicios de lectura y escritura. A continuación, se detallan algunas de estas ven-tajas:

08192


t. de regiones

t. páginas

00000 I 000


.........

0

8192

16384

Memoria

Código

C0000000

8192

16384


......................... ........

20480 81928192


163844096


Fichero F

00000 I 000

Swap (SW1)

.........


BFFFF000 Pila

00002 I SW100000 I 000................

BFFFF0004096


00004 V R-X

00001 I SW1

P gina 0 de P1 P2á

BCP de P1



.........

0

8192

16384

Código

C0000000

8192

1638420480


BFFFF000 Pila


P gina 4 de P1 P2á

00004 V R--

08192


t. de regiones

t. páginas

00000 I 000

81928192


163844096


00000 I 000

.........

00002 I SW100000 I 000................

BFFFF0004096


00004 V R-X

00001 I SW1

BCP de P2

00004 V R--

Fichero.........

Fichero

Bloq. 0

.........

Bloq. 1Bloq. 2


Figura 5.76 Resultado de la llamada fork.


• Se disminuye considerablemente el número de llamadas al sistema necesarias para acceder a un fi-chero. Con esta nueva técnica, una vez que el fichero está proyectado, no hay que realizar ninguna llamada adicional. Esta reducción implica una mejora considerable en los tiempos de acceso, puesto que, como ya es conocido, la activación de una llamada al sistema tiene asociada una considerable sobrecarga.

• Se evitan copias intermedias de la información. Esto repercute también en un acceso más eficiente. Con esta técnica, el sistema operativo transfiere directamente la información entre la memoria y el fichero. Con la forma de acceso convencional, todas las transferencias se realizan pasando por la caché de bloques del sistema de ficheros.

• Se facilita la forma de programar los accesos a los ficheros. Una vez proyectado el fichero, se accede al mismo igual que a cualquier estructura de datos en memoria que haya declarado el programa. No es necesario utilizar ningún servicio especial del sistema operativo para acceder al mismo. Así, por ejemplo, dado un programa que realiza un cierto tratamiento sobre una matriz de datos almacenada en memoria, su modificación para que leyera la matriz de un fichero sólo implicaría añadir al princi-pio del programa la proyección del fichero. No sería necesario modificar el código restante.

5.6. SERVICIOS DE GESTIÓN DE MEMORIA

Como se ha podido apreciar a lo largo del capítulo, las labores que lleva a cabo el sistema de gestión de me-moria son más bien de carácter interno. Más que proporcionar una colección de servicios explícitos a las aplicaciones, el objetivo del sistema de memoria tiene un carácter más implícito: dotar a las aplicaciones de un espacio de almacenamiento para su ejecución que satisfaga las necesidades de las mismas. Además, algu-nos servicios de gestión de memoria usados por los programas, como, por ejemplo, los vinculados con el uso de memoria dinámica, no son labor directa del sistema operativo, sino que los suministra el propio lenguaje de programación. Debido a todo ello, este componente del sistema operativo apenas ofrece servicios directos a las aplicaciones. Entre ese número relativamente reducido de servicios, en esta sección se ha considerado que los de mayor interés se pueden agrupar en dos categorías:

BCP

t. de regiones

t. páginas

00000 I 000

Mapa de memoria


.........

CódigoFichero

20480

.........

2048040000

RW- CompF Bl. inicial 0

Fichero F

00000 I 000

.........


Pila

00000 I 000................00000 I 000


MemoriaMarco 0Marco 1Marco 2Marco 3Marco 4

......................... .................00000 I 000................

............

............

............

............

............

............

............

............

............

............Fichero proyectado F

00004 V RW-

Bloque 0 de F

Figura 5.77 Proyección de un fichero.


• Servicios de proyección de ficheros, que permiten incluir en el mapa de memoria de un proceso un fichero o parte del mismo. Bajo esta categoría existirán, básicamente, dos servicios:

⎯ Proyección de un fichero. Con esta operación se crea una región asociada al objeto de me-moria almacenado en el fichero. Normalmente, se pueden especificar algunas propiedades de esta nueva región. Por ejemplo, el tipo de protección o si la región es privada o compartida.

⎯ Desproyección de un fichero. Este servicio elimina una proyección previa o parte de la mis-ma.

• Servicios de montaje explícito de bibliotecas, que permiten que un programa cargue en tiempo de ejecución una biblioteca dinámica y use la funcionalidad proporcionada por la misma, tal como se analizó en la sección 5.3.2. En esta categoría se englobarían, básicamente, tres servicios:

⎯ Carga de la biblioteca. Este servicio realiza la carga de la biblioteca, llevando a cabo todas las operaciones de montaje requeridas.

⎯ Acceso a un símbolo de la biblioteca. Con esta operación, el programa puede tener acceso a uno de los símbolos exportados por la biblioteca, ya sea éste una función o una variable.

⎯ Descarga de la biblioteca. Este servicio elimina la biblioteca del mapa del proceso. En las siguientes secciones, se muestran los servicios proporcionados por UNIX y Windows dentro de

estas dos categorías.

5.6.1. Servicios UNIX de proyección de ficheros

Los servicios de gestión de memoria más frecuentemente utilizados son los que permiten la proyección y desproyección de ficheros (mmap, munmap).

caddr_t mmap (caddr_t direccion, size_t longitud, int protec, int indicadores, int descriptor, off_t despl);

Este servicio proyecta el fichero especificado creando una región con las características indicadas en la lla-mada. El primer parámetro indica la dirección del mapa donde se quiere que se proyecte el fichero. General-mente, se especifica un valor nulo para indicar que se prefiere que sea el sistema el que decida donde proyectar el fichero. En cualquier caso, la función devolverá la dirección de proyección utilizada.

El parámetro descriptor corresponde con el descriptor del fichero que se pretende proyectar (que debe estar previamente abierto), y los parámetros despl y longitud establecen qué zona del fichero se proyecta: desde la posición despl hasta desp + longitud.

El argumento protec establece la protección de la región, que puede ser de lectura (PROT_READ), de escritura (PROT_WRITE), de ejecución (PROT_EXEC), o cualquier combinación de ellas. Esta protección debe ser compatible con el modo de apertura del fichero. Por último, el parámetro indicadores permite establecer ciertas propiedades de la región:

• MAP_SHARED. La región es compartida. Las modificaciones sobre la región afectarán al fichero. Un proceso hijo compartirá esta región con el padre.

• MAP_PRIVATE. La región es privada. Las modificaciones sobre la región no afectarán al fichero. Un proceso hijo no compartirá esta región con el padre, sino que obtendrá un duplicado de la misma.

• MAP_FIXED. El fichero debe proyectarse justo en la dirección especificada en el primer parámetro. Esta opción se utiliza, por ejemplo, para cargar el código de una biblioteca dinámica, si en el sistema se utiliza un esquema de gestión de bibliotecas dinámicas, tal que cada biblioteca tiene asignado un rango de direcciones fijo.

En el caso de que se quiera proyectar una región sin soporte (región anónima), en algunos sistemas se puede especificar el valor MAP_ANON en el parámetro indicadores. Otros sistemas UNIX no ofrecen


esta opción, pero permiten proyectar el dispositivo /dev/zero para lograr el mismo objetivo. Esta opción se puede usar para cargar la región de datos sin valor inicial de una biblioteca dinámica.

int munmap(caddr_t direccion, size_t longitud);

Este servicio elimina una proyección previa o parte de la misma. Los parámetros direccion y longituddefinen la región (o la parte de la región) que se quiere eliminar del mapa del proceso.

Antes de presentar ejemplos del uso de estos servicios, hay que aclarar que se utilizan conjuntamente con los servicios de manejo de ficheros que se presentarán en el capítulo que trata este tema. Por ello, para una buena comprensión de los ejemplos, se deben estudiar también los servicios explicados en ese capítulo.

A continuación, se muestran dos ejemplos del uso de estas funciones. El primero es el programa 5.5 que cuenta cuántas veces aparece un determinado carácter en un fichero utilizando la técnica de proyección en memoria.

Programa 5.5 Programa que cuenta el número de apariciones de un carácter en un fichero.

#include <sys/types.h>#include <sys/stat.h>#include <sys/mman.h>#include <fcntl.h>#include <stdio.h>#include <unistd.h>int main(int argc, char *argv[]) { int i, fd, contador=0; char caracter; char *org, *p; struct stat bstat;

if (argc!=3) { fprintf (stderr, ”Uso: %s caracter fichero\n”, argv[0]); return 1; } /* Para simplificar, se supone que el carácter a contar corresponde con el primero del primer argumento */ caracter=argv[1][0]; /* Abre el fichero para lectura */ if ((fd=open(argv[2], O_RDONLY))<0) { perror(”No puede abrirse el fichero”); return 1; } /* Averigua la longitud del fichero */ if (fstat(fd, &bstat)<0) { perror(”Error en fstat del fichero”);

close(fd); return 1; } /* Se proyecta el fichero */ if ((org=mmap((caddr_t) 0, bstat.st_size, PROT_READ, MAP_SHARED, fd, 0)) == MAP_FAILED) { perror(”Error en la proyeccion del fichero”);

close(fd); return 1; }


/* Se cierra el fichero */close(fd);

/* Bucle de acceso */ p=org; for (i=0; i<bstat.st_size; i++) if (*p++==caracter) contador++; /* Se elimina la proyeccion */

munmap(org, bstat.st_size); printf(”%d\n”, contador); return 0;}

El segundo ejemplo se corresponde con el programa 5.6 que usa la técnica de proyección para realizar la copia de un fichero. Observe el uso del servicio ftruncate para asignar espacio al fichero destino.

Programa 5.6 Programa que copia un fichero.

#include <sys/types.h>#include <sys/stat.h>#include <sys/mman.h>#include <fcntl.h>#include <stdio.h>#include <unistd.h>void main(int argc, char *argv[]) { int i, fdo, fdd; char *org, *dst, *p, *q; struct stat bstat;

if (argc!=3) { fprintf (stderr, ”Uso: %s orig dest\n”, argv[0]); return 1; } /* Abre el fichero origen para lectura */ if ((fdo=open(argv[1], O_RDONLY))<0) { perror(”No puede abrirse el fichero origen”); return 1; } /* Crea el fichero destino */ if ((fdd=open(argv[2], O_CREAT|O_TRUNC|O_RDWR, 0640))<0) { perror(”No puede crearse el fichero destino”);

close(fdo); return 1; } /* Averigua la longitud del fichero origen */ if (fstat(fdo, &bstat)<0) { perror(”Error en fstat del fichero origen”);

close(fdo); close(fdd); unlink(argv[2]); return 1; }


/* Establece que la longitud del fichero destino es igual a la del origen.*/ if (ftruncate(fdd, bstat.st_size)<0) { perror(”Error en ftruncate del fichero destino”);

close(fdo); close(fdd); unlink(argv[2]); return 1; } /* Se proyecta el fichero origen */ if ((org=mmap((caddr_t) 0, bstat.st_size, PROT_READ, MAP_SHARED, fdo, 0)) == MAP_FAILED) { perror(”Error en la proyeccion del fichero origen”);

close(fdo); close(fdd); unlink(argv[2]); return 1; } /* Se proyecta el fichero destino */ if ((dst=mmap((caddr_t) 0, bstat.st_size, PROT_WRITE, MAP_SHARED, fdd, 0)) == MAP_FAILED) { perror(”Error en la proyeccion del fichero destino”);

close(fdo); close(fdd); unlink(argv[2]); return 1; } /* Se cierran los ficheros */

close(fdo);close(fdd);

/* Bucle de copia */ p=org; q=dst; for (i=0; i<bstat.st_size; i++) *q++= *p++; /* Se eliminan las proyecciones */

munmap(org, bstat.st_size);munmap(dst, bstat.st_size);

return 0;}

5.6.2. Servicios UNIX de carga de bibliotecas

Por lo que se refiere a esta categoría, la mayoría de los sistemas UNIX ofrece las funciones dlopen, dlsymy dlclose.

void *dlopen(const char *biblioteca, int indicadores);

La rutina dlopen realiza la carga y montaje de una biblioteca dinámica. Recibe como argumentos el nombre de la biblioteca y el valor indicadores, que determina diversos aspectos vinculados con la carga de la biblioteca. Como resultado, esta función devuelve un descriptor que identifica dicha biblioteca cargada. En cuanto al segundo parámetro, aunque permite especificar distintas posibilidades a la hora de cargarse la bi-blioteca, de forma obligatoria, sólo es necesario indicar uno de los dos siguientes valores: RTLD_LAZY, que indica que las referencias a símbolos que estén pendientes de resolver dentro de la biblioteca no se llevarán a cabo hasta que sea estrictamente necesario, o RTLD_NOW, que especifica que durante la propia llamada dlopen se resuelvan todas las referencias pendientes que haya dentro de la biblioteca que se desea cargar. Recuerde que estos dos modos de operación se analizaron cuando se estudiaron los aspectos de implementa-ción de las bibliotecas dinámicas.


void *dlsym(void *descriptor, char *simbolo);

La función dlsym permite acceder a uno de los símbolos exportados por la biblioteca. Recibe como paráme-tros el descriptor de una biblioteca dinámica previamente cargada y el nombre de un símbolo (una variable o una función). Este servicio se encarga de buscar ese símbolo dentro de la biblioteca especificada y devuelve la dirección de memoria donde se encuentra dicho símbolo. Como primer parámetro, en vez de un descriptor de biblioteca, se puede especificar la constante RTLD_NEXT. Si desde una biblioteca dinámica se invoca a la función dlsym especificando esa constante, el símbolo se buscará en las siguientes bibliotecas dinámicas del proceso a partir de la propia biblioteca que ha invocado la función dlsym, en vez de buscarlo empezando por la primera biblioteca dinámica especificada en el mandato de montaje. Esta característica suele usarse cuando se pretende incluir una función de interposición que, además, después invoque la función original.

int dlclose(void *descriptor);

La rutina dlclose descarga la biblioteca especificada por el descriptor. A continuación, se incluye el programa 5.7 que muestra un ejemplo del uso de estas funciones. El pro-

grama recibe como argumentos el nombre de una biblioteca dinámica, el nombre de una función y el paráme-tro que se le quiere pasar a la función. Esta función debe ser exportada por la biblioteca, debe tener un único parámetro de tipo cadena de caracteres y devolver un valor entero. El programa carga la biblioteca e invoca la función pasándole el argumento especificado, imprimiendo el resultado devuelto por la misma.

Programa 5.7 Programa que ejecuta una función exportada por una biblioteca dinámica.

#include <stdio.h>#include <unistd.h>#include <dlfcn.h>#include <string.h>#include <stdlib.h>int main(int argc, char *argv[]) { void *descriptor_bib; int (*procesar)(char *); int resultado; if (argc!=4) { fprintf(stderr, "Uso: %s biblioteca funcion argumento\n", argv[0]); return 1; } /* Se carga la biblioteca dinámica */ if (!(descriptor_bib=dlopen(argv[1], RTLD_LAZY))) { fprintf(stderr, "Error cargando biblioteca: %s\n", dlerror()); return 1; } /* Busca el símbolo */ if (!(procesar=dlsym(descriptor_bib, argv[2]))) { fprintf(stderr, "Error: biblioteca no incluye la funcion\n"); return 1; } /* Finalmente, llamamos a la función */ resultado=procesar(argv[3]); printf("Resultado: %d\n", resultado); /* Se descarga la biblioteca */

dlclose(descriptor_bib); return 0;}


5.6.3. Servicios Windows de proyección de ficheros

A diferencia de UNIX, en Windows, la proyección de un fichero se realiza en dos pasos. En primer lugar, hay que crear una proyección del fichero y, posteriormente, se debe crear una región en el proceso que esté asociada a la proyección.

HANDLE CreateFileMapping(HANDLE fich, LPSECURITY_ATTRIBUTES segur, DWORD prot, DWORD tamaño_max_alta, DWORD tamaño_max_baja, LPCTSTR nombre_proy);

Esta función crea una proyección de un fichero. Como resultado de la misma, devuelve un identificador de la proyección. Recibe como parámetros el nombre del fichero, un valor de los atributos de seguridad, la protec-ción, el tamaño del objeto a proyectar (especificando la parte alta y la parte baja de este valor en dos paráme-tros independientes) y un nombre para la proyección.

En cuanto a la protección, puede especificarse de sólo lectura (PAGE_READONLY), de lectura y escritu-ra (PAGE_READWRITE) o privada (PAGE_WRITECOPY). Con respecto al tamaño, en el caso de que el fichero pueda crecer, se debe especificar el tamaño esperado para el fichero. Si se especifica un valor 0, se usa el tamaño actual del fichero. Por último, por lo que se refiere al nombre de la proyección, éste permite a otros procesos acceder a la misma. Si se especifica un valor nulo, no se asigna nombre a la proyección.

LPVOID MapViewOfFile(HANDLE id_proy, DWORD acceso, DWORD desp_alta,DWORD desp_baja, DWORD tamaño);

Esta función crea una región en el mapa del proceso que queda asociada con una proyección previamente creada. Al completarse, esta rutina devuelve la dirección del mapa donde se ha proyectado la región. Recibe como parámetros el identificador de la proyección devuelto por CreateFileMapping, el tipo de acceso solicitado (FILE_MAP_WRITE, FILE_MAP_READ y FILE_MAP_ALL_ACCESS), que tiene que ser com-patible con la protección especificada en la creación, el desplazamiento con respecto al inicio del fichero a partir del que se realiza la proyección, y el tamaño de la zona proyectada (el valor cero indica todo el fiche-ro).

BOOL UnmapViewOfFile(LPVOID dir);

Esta función elimina la proyección del fichero. El parámetro indica la dirección de comienzo de la región que se quiere eliminar.

A continuación, se muestran los dos mismos ejemplos que se plantearon en la sección dedicada a este tipo de servicios en UNIX. Como se comentó en dicha sección, es necesario conocer los servicios básicos de ficheros para entender completamente los siguientes programas. El primero es el programa 5.8 que cuenta cuántas veces aparece un determinado carácter en un fichero usando la técnica de proyección en memoria.

Programa 5.8 Programa que cuenta el número de apariciones de un carácter en un fichero.

#include <windows.h>#include <stdio.h>

int main (int argc, char *argv[]) { HANDLE hFich, hProy; LPSTR base, puntero; DWORD tam; int contador=0; char caracter;

if (argc!=3) { fprintf (stderr, "Uso: %s caracter fichero\n", argv[0]); return 1; }


/* Para simplificar, se supone que el carácter a contar corresponde con el primero del primer argumento */ caracter=argv[1][0]; /* Abre el fichero para lectura */ hFich = CreateFile(argv[2], GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (hFich == INVALID_HANDLE_VALUE) { fprintf(stderr, ”No puede abrirse el fichero\n”); return 1; } /* se crea la proyección del fichero */ hProy = CreateFileMapping(hFich, NULL, PAGE_READONLY, 0, 0, NULL); if (hProy == INVALID_HANDLE_VALUE) { fprintf(stderr, ”No puede crearse la proyección\n”); return 1; } /* se realiza la proyección */ base = MapViewOfFile(hProy, FILE_MAP_READ, 0, 0, 0); tam = GetFileSize(hFich, NULL); /* bucle de acceso */ puntero = base; while (puntero < base + tam) if (*puntero++==caracter) contador++; printf("%d\n", contador); /* se elimina la proyección y se cierra el fichero */

UnmapViewOfFile(base);CloseHandle(hProy);CloseHandle(hFich);

return 0;}

El segundo ejemplo se corresponde con el programa 5.9 que usa la técnica de proyección para realizar la copia de un fichero.

Programa 5.9 Programa que copia un fichero.

#include <windows.h>#include <stdio.h>

int main (int argc, char *argv[]){ HANDLE hEnt, hSal; HANDLE hProyEnt, hProySal; LPSTR base_orig, puntero_orig; LPSTR base_dest, puntero_dest; DWORD tam;

if (argc!=3){ fprintf (stderr, "Uso: %s origen destino\n", argv[0]); return 1; }


/* se abre el fichero origen */ hEnt = CreateFile (argv[1], GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (hEnt == INVALID_HANDLE_VALUE) { fprintf(stderr, ”No puede abrirse el fichero origen\n”); return 1; }

/* se crea la proyección del fichero origen */ hProyEnt = CreateFileMapping(hEnt, NULL, PAGE_READONLY, 0, 0, NULL); if (hProyEnt == INVALID_HANDLE_VALUE) { fprintf(stderr, ”No puede crearse proyección del fichero origen\n”); return(1); } /* se proyecta el fichero origen */ base_orig = MapViewOfFile(hProyEnt, FILE_MAP_READ, 0, 0, 0); tam = GetFileSize (hEnt, NULL); /* se crea el fichero destino */ hSal = CreateFile(argv[2], GENERIC_READ | GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); if (hSal == INVALID_HANDLE_VALUE) { fprintf(stderr, ”No puede crearse el fichero destino\n”); return 1; } /* se crea la proyección del fichero destino */ hProySal = CreateFileMapping(hSal, NULL, PAGE_READWRITE, 0, tam, NULL); if (hProySal == INVALID_HANDLE_VALUE) { fprintf(stderr, ”No puede crearse proyección del fichero destino”); return 1; } /* se proyecta fichero destino */ base_dest = MapViewOfFile(hProySal, FILE_MAP_WRITE, 0, 0, tam); /* bucle de copia */ puntero_orig = base_orig; puntero_dest = base_dest; for ( ; puntero_orig < base_orig + tam; puntero_orig++, puntero_dest++) *puntero_dest = *puntero_orig; /* se eliminan proyecciones y se cierran ficheros */

UnmapViewOfFile(base_dest);UnmapViewOfFile(base_orig);CloseHandle(hProyEnt);CloseHandle(hEnt);CloseHandle(hProySal);CloseHandle(hSal);

return 0;}


5.6.4. Servicios Windows de carga de bibliotecas

En esta categoría, Windows ofrece las funciones LoadLibrary, GetProcAddress y FreeLibrary.HINSTANCE LoadLibrary(LPCTSTR biblioteca);

La rutina LoadLibrary realiza la carga y montaje de una biblioteca dinámica. Recibe como argumento el nombre de la biblioteca.

FARPROC GetProcAddress(HMODULE descriptor, LPCSTR simbolo);

La función GetProcAddress permite acceder a uno de los símbolos exportados por la biblioteca. Recibe como parámetros el descriptor de una biblioteca dinámica previamente cargada y el nombre de un símbolo. Este servicio se encarga de buscar ese símbolo dentro de la biblioteca especificada y devuelve la dirección de memoria donde se encuentra dicho símbolo.

BOOL FreeLibrary(HINSTANCE descriptor);

La rutina FreeLibrary descarga la biblioteca especificada por el descriptor. A continuación, en el programa 5.10 se muestra el mismo ejemplo que se planteó para UNIX en el pro-

grama 5.7.

Programa 5.10 Programa que ejecuta una función exportada por una biblioteca dinámica.

#include <windows.h>#include <stdio.h>int main(int argc, char *argv[]) { HINSTANCE descriptor_bib; int (*procesar)(LPCTSTR); int resultado;

if (argc!=4) { fprintf(stderr, "Uso: %s biblioteca funcion argumento\n", argv[0]); return 1; } /* Se carga la biblioteca dinámica */ descriptor_bib = LoadLibrary(argv[1]); if (descriptor_bib == NULL) { fprintf(stderr, "Error cargando biblioteca %s\n", argv[1]); return 1; } procesar = (int(*)(LPCTSTR))GetProcAddress(descriptor_bib, argv[2]); if (procesar == NULL) { /* La función no existe */ fprintf(stderr, "Error: biblioteca no incluye la funcion\n"); return 1; } /* Finalmente, llamamos a la función */ resultado=procesar(argv[3]); printf("Resultado: %d\n", resultado); /* Se descarga la biblioteca */

FreeLibrary(descriptor_bib); return 0;}


5.7. LECTURAS RECOMENDADAS

Dada la variedad de temas abordados en este capítulo, al intentar dar una visión integral de la gestión de me-moria, se recomiendan lecturas de muy diversa índole. Para profundizar en los aspectos relacionados con el ciclo de vida de un programa, se recomienda al lector interesado la consulta del libro [Levine, 1999]. En cuanto a la gestión del heap y, en general, el problema general de la asignación de espacio, es aconsejable el artículo [Wilson, 1995]. Dada la fuerte dependencia del hardware que existe en el sistema de memoria, es obligado hacer alguna referencia a documentación sobre los esquemas hardware de gestión de memoria ([Ja-cob, 1998]). Asimismo, se aconseja la revisión de documentación sobre aspectos menos convencionales, ya sea por su carácter novedoso o por ser avanzados, tales como nuevos algoritmos de reemplazo de memoria virtual ([Megiddo, 2004]) o sistemas basados en un espacio de direcciones único ([Chase, 1994]).

Todos los libros generales de sistemas operativos (como, por ejemplo, [Silberschatz, 2005], [Stallings, 2005], [Nutt, 2004] y [Tanenbaum, 2001]) incluyen uno o más capítulos dedicados a la gestión de memoria, aunque, en nuestra opinión, seguramente interesada, no usan el enfoque integral de la gestión de memoria que se ha utilizado en este capítulo, por lo que su extensión es menor que la del presente capítulo.

Para ampliar conocimientos sobre la implementación de la gestión de la memoria en diversos sistemas operativos, en el caso de Linux, se pueden consultar [Gorman, 2004], [Mosberger, 2002] y [Bovet, 2005], para UNIX BSD, [McKusick, 2004], y, por lo que se refiere a Windows, [Russinovich, 2005]. Por el impacto y la innovación que causaron en su momento en el campo de la gestión de memoria, son de especial interés los sistemas operativos MULTICS [Organick, 1972] y Mach [Rashid, 1988].

En cuanto a los servicios de gestión de memoria, en [Stevens, 1999] se presentan los servicios de UNIX y en [Hart, 2004] los de Windows.

5.8. EJERCICIOS

5.1. ¿Cuál de las siguientes técnicas favorece la proximidad de referencias?a) Un programa multithread.b) El uso de listas. c) La programación funcional. d) La programación estructurada.

5.2. Considere un sistema de paginación con un tamaño de página P. Especifique cuál sería la fórmula que determina la dirección de memoria física F a partir de la dirección virtual D, siendo MARCO(X) una función que devuelve qué número de marco está almacenado en la entrada X de la tabla de páginas.

5.3. ¿Es siempre el algoritmo LRU mejor que el FIFO? En caso de que sea así, plantee una demostración. En caso negativo, proponga un contraejemplo.

5.4. Aplique el modelo de coherencia propuesto en la sección 5.5.13 al nivel de registros.

5.5. En el lenguaje C se define el calificador volatile aplicable a variables. La mi-sión de este calificador es evitar problemas de coherencia en aquellas variables a las que se accede tanto desde el flujo de ejecu-

ción normal como desde flujos asíncronos, como por ejemplo una rutina asociada a una señal UNIX. Analice los tipos de pro-blemas que podrían aparecer y proponga un método para resolver los problemas identi-ficados para las variables etiquetadas con este calificador.

5.6. Algunas MMU no proporcionan un bit de referencia para la página. Proponga una manera de simularlo. Una pista: Se pueden forzar fallos de página para detectar acce-sos a una página.

5.7. Algunas MMU no proporcionan un bit de página modificada. Proponga una manera de simularlo.

5.8. Escriba un programa que use los servicios de proyección de ficheros de UNIX para comparar dos ficheros.

5.9. Escriba un programa que use los servicios de proyección de ficheros de Windows para comparar dos ficheros.

5.10. Determine qué número de fallos de página se producen al utilizar el algoritmo FIFO teniendo 3 marcos y cuántos con 4 marcos. Compárelo con el algoritmo LRU. ¿Qué ca-


racteriza a los algoritmos de reemplazo de pila?

5.11. La secuencia que se utiliza habitualmente como ejemplo de la anomalía de Belady es la siguiente:

1 2 3 4 1 2 5 1 2 3 4 5

5.12. Suponiendo que se utiliza un sistema sin buffering de páginas, proponga ejemplos de las siguientes situaciones: a) Fallo de página sin operaciones de E/S. b) Fallo de página con sólo una operación

de lectura. c) Fallo de página con sólo una operación

de escritura. d) Fallo de página con una operación de

lectura y una de escritura. 5.13. Repita el ejercicio anterior, suponiendo un

sistema con buffering de páginas. 5.14. Considere un sistema de memoria virtual

sin buffering de páginas. Realice un análisis de cómo evoluciona una página en este sis-tema dependiendo de la región a la que per-tenece. Estudie los siguientes tipos: a) Página de código. b) Página de datos con valor inicial. c) Página de datos sin valor inicial. d) Página de un fichero proyectado. e) Página de zona de memoria compartida.

5.15. Resuelva el ejercicio anterior suponiendo que hay buffering de páginas.

5.16. Como se comentó en la explicación del algoritmo de reemplazo LRU, el tiempo que se debe usar para seleccionar la página menos recientemente usada es el tiempo lógico de cada proceso y no el tiempo real. Modifique la implementación basada en contadores propuesta en el texto para que tenga en cuenta esta consideración.

5.17. En el texto sólo se ha planteado un bosque-jo del algoritmo de reemplazo LFU. Expli-que cómo se podría diseñar una MMU que usara este algoritmo. Acto seguido, descri-ba una aproximación del mismo usando sólo un bit de referencia.

5.18. Complete la rutina de tratamiento de fallo de página presentada en la sección 5.5.7 con todos los aspectos que se han ido aña-diendo en las secciones posteriores (caché de páginas y buffering, utilización de pre-asignación de swap o no, creación de tablas

de páginas por demanda, expansión implí-cita de la pila, etc.).

5.19. Algunas versiones de UNIX realizan la carga de las bibliotecas dinámicas usando el servicio mmap. Explique qué parámetros deberían especificarse para cada una de las secciones de una biblioteca.

5.20. Acceda en un sistema Linux al fichero /proc/self/maps y analice cuál es su contenido. ¿A qué estructura de datos del sistema de gestión de memoria corresponde el contenido de este fichero?

5.21. En Windows se pueden crear múltiples heaps. Analice en qué situaciones puede ser interesante esta característica.

5.22. Algunas versiones de UNIX ofrecen una llamada denominada vfork que crea un hijo que utiliza directamente el mapa de memoria del proceso padre, que se queda bloqueado hasta que el hijo ejecuta una llamada exec o termina. En ese momento el padre recupera su mapa. Analice qué ventajas y desventajas presenta el uso de este nuevo servicio frente a la utilización del fork convencional. En este análisis suponga primero que el fork se imple-menta sin usar la técnica COW para, a con-tinuación, considerar que sí se utiliza.

5.23. Analice qué puede ocurrir en un sistema que utiliza paginación por demanda si se recompila un programa mientras se ejecuta. Proponga soluciones a los problemas que pueden surgir en esta situación.

5.24. En UNIX se define el servicio msync que permite forzar la escritura inmediata de una región en su soporte. ¿En qué situaciones puede ser interesante usar esta función?

5.25. Analice qué situaciones se pueden producir en el tratamiento de un fallo de TLB en un sistema que tiene una gestión software de la TLB.

5.26. Con el uso de la técnica de proyección de ficheros se produce una cierta unificación entre el sistema de ficheros y la gestión de memoria. Puesto que, como se verá en el capítulo dedicado a los ficheros, el sistema de ficheros usa una caché de bloques con escritura diferida para acelerar el acceso al disco. Analice qué tipo de inconsistencias pueden producirse si se accede a un fichero utilizando una proyección y los servicios convencionales del sistema de ficheros.


5.27. Analice el uso de la técnica del COW para optimizar una función de paso de mensajes entre los procesos de una misma máquina.

5.28. Sea un proceso en cuyo mapa de memoria existe una región privada con soporte en fi-chero. El proceso va invocar la llamada exec. ¿En qué ubicaciones pueden estar las páginas de la región en el instante pre-vio? ¿Qué tratamiento se realiza sobre esa región durante la llamada exec?

5.29. Basándose en la manera como se utilizan habitualmente las llamadas fork y execen las aplicaciones, algunos proponen que sería más eficiente que después del forkse ejecutara primero el proceso hijo en vez del padre. Analice en qué puede basarse es-ta propuesta.

5.30. Considere un proceso Pr1 en cuyo mapa de memoria se incluye una región privada con soporte en fichero, que está formada por 3 páginas. Suponga que se ejecuta la traza que se muestra a continuación y que des-pués de ejecutar esta traza entran a ejecutar otros procesos que expulsan las páginas de estos procesos. Se debe calcular cuántos bloques de swap se dedican en total a esta región y, para cada proceso, cuál es la ubi-cación de cada página de la región, identifi-cando en qué bloque del fichero o del swapestá almacenada (numere los bloques del swap como considere oportuno). a) Pr1: lee de la página 1. b) Pr1: escribe en las páginas 2 y 3. c) Pr1: fork (crea Pr2). d) Pr1: escribe en las páginas 1 y 2. e) Pr2: escribe en la página 2. f) Pr2: fork (crea Pr3). g) Pr2: escribe en las páginas 1 y 3. h) Pr3: lee de las páginas 1, 2 y 3.

5.31. Muchos sistemas operativos mantienen una estadística de cuántos fallos de página se producen en el sistema que no implican una operación de lectura de disco (en Linux se denominan minor faults y en Windows soft faults). Suponga que se utiliza un sistema de memoria virtual basado en paginación por demanda, sin buffering de páginas. Analice si se produciría un fallo de página (ya sea convencional o el asociado al COW) y, en caso afirmativo, si implicaría una lectura de disco o no, para cada una de las situaciones que se plantean a continua-

ción. En caso de que haya lectura, especifi-que si es de un fichero o de swap; en caso de que no la haya, explique si se requiere un marco libre para servir el fallo y qué in-formación se almacena en el mismo. a) Después de reservar memoria dinámica,

el proceso escribe en la misma. b) Después de llevar a cabo una llamada a

procedimiento que hace que la región de pila se expanda, el proceso modifica una variable local.

c) El proceso lee una variable global sin valor inicial que modificó antes, pero cuya página no está actualmente presen-te.

d) Un proceso escribe en una variable glo-bal con valor inicial a la que ha accedi-do previamente sin modificarla, pero cuya página no está actualmente presen-te.

e) Inmediatamente a continuación de que un proceso modifique una variable glo-bal con valor inicial y, luego, cree un hijo (fork), el proceso hijo lee esa misma variable.

f) Inmediatamente a continuación de que un proceso lea una variable global con valor inicial y, luego, cree un hijo (fork), el hijo escribe en esa misma variable.

g) Inmediatamente a continuación de que un proceso modifique una variable glo-bal con valor inicial y, luego, cree un thread, el nuevo thread escribe en esa misma variable.

h) Analice cómo afectaría a esta estadística el uso del buffering de páginas. ¿Habría nuevas situaciones de fallos sin lectura de disco? ¿Dejaría de haber algunas de las situaciones de fallos sin lectura de disco que existen en un sistema que no usa buffering?

5.32. Considérese una TLB convencional, que no incluye información de proceso, tal que ca-da entrada tiene la información habitual: número de página y de marco, permisos de acceso, y bits de referencia y de modifica-do. Supóngase que el procesador incluye dos instrucciones para que el sistema opera-tivo pueda manipular la TLB: una para in-validar la entrada vinculada a una página y otra para invalidar completamente el conte-


nido de la TLB. Analice de forma razonada si en cada una de las siguientes operacio-nes, el sistema operativo haría uso de algu-na de estas instrucciones, especificando, en el caso de que se invalide una entrada, a qué página correspondería: a) Hay un cambio de contexto entre dos

threads de distinto proceso. b) Hay un cambio de contexto entre dos

threads del mismo proceso. c) Se crea una nueva región en el mapa del

proceso. d) Se elimina una región del mapa del pro-

ceso.e) Cambia el tamaño de una región del

mapa del proceso. Analice separada-mente el caso del aumento de tamaño y el de la disminución.

f) Se marca como duplicada una región (por ejemplo, en el tratamiento de una región privada que forma parte de una llamada fork).

g) Hay un fallo de página que encuentra un marco libre.

h) Hay un fallo de página que no encuentra marcos libres. El sistema usa el algorit-mo de reemplazo del reloj y encuentra que la primera página candidata a ser expulsada tiene tanto el bit de referencia como el de modificado a 1, mientras que la segunda tiene ambos bits a 0.

i) Se produce un fallo debido al COW y el contador de referencias de la página es mayor que 1.

j) Se produce un fallo debido al COW y el contador de Y es igual a 1.

5.33. Supóngase un programa que proyecta un fichero de forma privada y que, luego, crea un proceso mediante fork y este proceso hijo, a su vez, crea un thread. Analice, de manera independiente, qué ocurriría en las siguientes situaciones: a) El thread modifica una determinada po-

sición de memoria asociada al fichero proyectado, luego la modifica el proce-so hijo y, por último, el padre.

b) El thread elimina la proyección del fi-chero y, acto seguido, intentan acceder a esa región el proceso hijo y el padre.

5.34. Sea un sistema con memoria virtual, en el que las direcciones lógicas que tienen un 0 en el bit de mayor peso son de usuario y las

que tienen un 1 son de sistema. Considérese que el sistema operativo no tiene ningún error de programación y que se produce un fallo de página tal que la dirección que lo provoca no pertenece a ninguna región del proceso. Dependiendo de en qué modo se ejecutaba el proceso cuando ocurrió el fallo y del tipo de la dirección de fallo, se dan los siguientes casos, cada uno de los cuales se deberá analizar para ver si es posible esa situación y, en caso afirmativo, explicar qué tratamiento requiere analizando si in-fluye en el mismo el valor del puntero de pila en el momento del fallo: a) El proceso se estaba ejecutando en mo-

do usuario y la dirección de fallo co-mienza con un 0.

b) El proceso se estaba ejecutando en mo-do usuario y la dirección de fallo co-mienza con un 1.

c) El proceso se estaba ejecutando en mo-do sistema y la dirección de fallo co-mienza con un 0. Distinga entre el caso de que el fallo se produzca durante una llamada al sistema o en una rutina de in-terrupción.

d) El proceso se estaba ejecutando en mo-do sistema y la dirección de fallo co-mienza con un 1. Distinga entre el caso de que el fallo se produzca durante una llamada al sistema o en una rutina de in-terrupción.

5.35. ¿Qué acciones sobre la TLB, la memoria caché y la tabla de páginas se realizan du-rante un cambio de contexto? Suponga dis-tintos tipos de hardware de gestión de memoria.

5.36. En un sistema con preasignación de swapse implantan dos cuotas máximas de uso de recursos por parte de un proceso: el tamaño máximo del mapa del proceso y el consumo máximo del espacio de swap por el proce-so. Analice razonadamente si en las si-guientes operaciones es necesario comprobar alguna de estas cuotas: a) Rutina de tratamiento del fallo de pági-

na.b) Proyección compartida de un fichero. c) Proyección privada de un fichero. d) Proyección privada de tipo anónima. e) Llamada al sistema fork.f) Rutina de tratamiento del COW.


g) ¿Habría que comprobar alguna de estas cuotas en la gestión del heap? En caso afirmativo, ¿en qué rutina del sistema operativo?

h) ¿Habría que comprobar alguna de estas cuotas en la gestión de la pila? En caso afirmativo, ¿en qué rutina del sistema operativo?

5.37. Una técnica perezosa en la gestión de me-moria es la paginación por demanda. Supo-niendo que existe suficiente memoria física, explique cuándo es beneficiosa, en cuanto a una ejecución más eficiente del proceso si se compara con la solución no perezosa, y

cuándo perjudicial y por qué motivo, en ca-so de que pueda serlo.

5.38. Responda a la misma cuestión sobre la técnica COW.

5.39. Durante el arranque, Linux almacena en un marco una página de sólo lectura llena de ceros, que se mantendrá así todo el tiempo, y que se usa para implementar una técnica perezosa en la gestión de páginas de una región anónima. Explique cómo sería esta técnica mostrando en qué situaciones puede ser beneficiosa y en cuáles perjudicial, si es que puede serlo.

Sistemas operativos -...

Documents

Transcript of Sistemas operativos -...