Memoria, parte 3 Algoritmos de reemplazo de páginas, cuestiones de diseño, segmentación

Reemplazo de páginas ● Si hay page fault => el SO tiene que seleccionar una página en memoria física que será eliminada en favor de la nueva p]agina ● Si la página a eliminar ha sido modificada debemos reescribirla en el HD ● Convenientemente, la página a eliminar no debería estar usándose activamente ● Esto daña la performance del sistema

Algoritmo óptimo de reeplazo de página ● Fácil de describir pero imposible de implementar: ● Cada página en memoria está etiquetada con la cantidad de instrucciones que se ejecutarán antes de que ésta sea referenciada ● Cuando ocurre un page fault, eliminar la página con la etiqueta más grande ● Osea, eliminamos la página que permanecerá ociosa por mayor tiempo ● Porqué es imposible de implementar? (similar problema al SJF). Se utiliza mas como benchmark...

Algoritmo NRU: not recently used ● Usa los bits R (referenced) y M (modified) en cada entrada de la tabla de página ● Los bits R y M se setean en 0 al cargar la página ● R se setea en 1 cada vez que la página es leída o escrita ● M se setea en 1 cada vez que la página es escrita ● Periódicamente (ej. en cada interrupción del reloj) el bit R se resetea a 0 (esto es para distinguir las páginas referenciadas recientemente de las que no).

NRU ● Cuando ocurre un page fault, el SO divide las páginas en memoria física en las siguientes clases: ● 0. not R y not M ● 1. not R y M ● 2. R y not M ● 3. R y M ● (Porqué el orden entre 1 y 2?) ● El NRU elije una página cualquiera de la clase mas baja disponible (ej, al azar o la 1era)

FIFO & segundo intento ● FIFO: Se elimina la página más vieja ● Osea la mas antiguamente cargada ● (vieja no significa menos usada!) ● Segundo intento: modificación del FIFO ● Antes de eliminar la página más vieja, se verifica el bit R – Si R=0, se elimina (y dependiendo del dirty M, se guarda en HD o no) – Si R=1, se resetea el R a cero, se reubica la página al final de la cola, y se reintenta con la siguiente página más vieja

Ejemplo Cuando el second chance se comporta igual que el FIFO?

Algoritmo del reloj ● Como el anterior pero en vez de usar una cola se usa una lista circular ● Hay un puntero “aguja del reloj” que apunta a la página más antigua ● Si R=0, se elimina ● Si R=1, se resetea R a cero y avanza la aguja ● Es más eficiente porque sólo necesita modificar el valor de un puntero (la aguja del reloj)

Ejemplo

Algoritmo Least Recently Used (LRU) ● Idea: eliminar las menos usadas frecuentemente (más preciso que el bit R) ● No es barato de implementar: ● mantener lista enlazada, ordenadas por + reciente a – reciente (caro de actualizar!) ● Usar un contador de HW (ej, de 64 bits) – El contador se actualiza automáticamente en cada pulso del reloj – Cada página guarda cdo fue accedida por última vez – En cada acceso a una página se actualiza con el valor del contador ● Page fault: elegir la página más vieja

LRU: esquema alternativo ● Se mantiene una matriz de nxn bits en HW (n= numero de frames), inicialmente todos ceros ● Cuando una página k es referenciada, el HW setea la fila k en 1s, y la columna k en 0s ● Qué efecto tiene esto? ● Hace que la fila k sea la mayor, achica toda j!=k (nunca hay una fila con ) ● La fila con menor valor binario es la más recientemente accedida, y así sucesivamente

Ejemplo

Algoritmo Not Frequently Used (NFU) ● El LRU requiere HW; para simularlo en Soft usamos el NFU ● Mantenemos un contador de “edad” por cada página, inicialmente en cero, y que se incrementa de acuerdo al bit R=0 o R=1. ● Cuando hay un page fault, elijo la página mas vieja (con contador menor) ● Problema: como nunca “olvidamos”, páginas viejas que fueron muy visitadas hace mucho tienen prioridad

Algoritmo Not Frequently Used (NFU) ● Solución (“aging”): agregar el bit R a la izq., y hacer shift-right ● Ver ejemplo ● Al ser finito el contador, perdemos precisión (más allá del tamaño máximo, una página puede haber sido muy referenciada y LRU la elegiría!)

Ejemplo

Algoritmo Working Set ● Los procesos exhiben “localidad de referencia”: hacen referencia a una fracción pequeña de sus páginas ● Idea: cargar de una vez (“pre-paginar”) todas esas páginas, llamadas el “working set” ● Si la memoria física es menor que el conjunto de trabajo, se producirán page faults casi todo el tiempo, llamado “thrashing” o sobrepaginado

Tamaño del working set

Algoritmo Working Set ● Como calcular el working set? ● Elegir “edad máxima” k, y hacer que el conjunto de trabajo = páginas utilizadas en las k referencias a memoria más recientes ● Page fault: elegir una página que no está en el conjunto de trabajo, y desalojarla ● Implementación: mantener la edad “k” es caro. ● Variante: usar tiempo fijo (por ej., las páginas referenciadas en los últimos 10 ms) ● El tiempo es “virtual” para cada proceso!

Ejemplo

Algoritmo WSClock ● Como en el algoritmo del reloj, mantener una lista circular de páginas ● Inicialmente vacía, a medida que se cargan las páginas se agregan ● Cada entrada mantiene el tiempo de último uso como en el working set anterior, mas los bits R y M ● Page fault=> si la aguja apunta a una página con R=1, no la elegimos; la seteamos en 0 y avanzamos la aguja ● Si R=0, y la edad > t, desalojar sólo si está limpia

Algoritmo WSClock ● Si está sucia, se planifica para escritura en HD, pero se sigue buscando una página más antigua limpia avanzando la aguja del reloj ● Si ocurre una vuelta entera, puede ser que: ● 1) se planificó una escritura al menos ● 2) no se planificó ninguna escritura ● Caso 1): seguir buscando limpias, eventualmente se completará la escritura planificada ● Caso 2): elegir entre las páginas limpias, cualquiera o la actual

Ejemplo

comparación

Cuestiones de diseño de paginación ● 1. Reemplazo de páginas local o global ● Se debe elegir páginas de un mismo proceso o entre todos? – Locales=>más justos pero más ineficientes – Globales=>más ineficientes (especialmente cuando los procesos varían dinámicamente en su necesidades de memoria) ● Además: debemos asignar marcos de páginas equitativamente entre todos los procesos activos, o asignar marcos de página en forma proporcional al tamaño del proceso?

Cuestiones de diseño de paginación ● 2. Control de carga: ● Para evitar sobrepaginación, hay que evitar tener demasiados procesos activos. Solución: mandar algunos procesos al HD, y periódicamente intercambiarlos ● 3. Tamaño de página ● Es parametrizable, pero que valor elegir? – Si es demasiado grande=>fragmentación interna – Demasiado chico=>demasiadas páginas

Cuestiones de diseño de paginación ● p=tamaño de página ● s=tamaño de proceso (promedio) ● e=tamaño de entrada en tabla de página ● s/p=número de páginas necesarias ● s.e/p=tamaño en bytes de páginas en tabla ● Grande cuando las páginas son chicas ● p/2=tamaño desperdiciado en la última página (promedio) ● Grande cuando las páginas son grandes

Cuestiones de diseño de paginación ● Sobrecarga por proceso: s.e/p + p/2 ● El mínimo es p = (2se)^(1/2) ● Para s=1MB, e=8B, el tamaño óptimo de pagina es p=4KB

Cuestiones de diseño de paginación ● Normalmente dividimos las páginas de datos de las de código ● Páginas compartidas: ● Las páginas de solo lectura (por ej. el código) se pueden compartir. Entonces hay que tener cuidado cuando se desaloja una página que pertenece a A compartida con B, ya que B hará page fault ● También se pueden compartir datos. Por ejemplo, en un fork, el padre e hijo comparten las mismas páginas mientras ninguna escriba; en ese caso, se duplican las páginas accedidas (“copy on write”)

Ejemplo

Cuestiones de diseño de paginación ● Bibliotecas compartidas ● Idea: tener código muy utilizado (ej, libc) en un sólo lugar. Utilizamos menos HD (para cada proceso) y menos memoria. ● También soluciona el problema de actualizar la librería independientemente de los programas ● Problema: las direcciones se usan en la biblioteca no pueden ser absolutas, sino que dependen de cada proceso ● (por ejemplo, una función de la biblioteca que salta a la dirección X absoluta no funciona). Hay que usar direcciones relativas (ej, salta n bytes).

Cuestiones de diseño de paginación ● Archivos asociados: usar un pedazo de memoria como “archivo” (ver libro) ● Se usa para comunicación entre procesos ● Limpieza: para mejor performance, conviene asegurar una provisión de memoria libre con un “demonio de paginación” que periódicamente libera páginas (no sólo en un page fault), y que también limpia páginas sucias en el HD

Cuestiones de implementación ● El SO trabaja con paginación cuando: ● 1. crea un proceso – Determina espacio, crear e inicializar tabla de paginación, crear espacio swap, guarda todo en la tabla de procesos ● 2. ejecuta – Resetea el MMU y TLB para el nuevo proceso, y actualiza tabla de procesos ● 3. Page fault – Encontrar en el HD la página que se necesita, buscar un nuevo frame de página (desalojar otro si hace falta), volver al punto de ejecución ● 4. termina – Liberar todo (memoria+HD), teniendo cuidado con datos compartidos, sólo el último los puede sacar!

Manejo de page fault en detalle ● 1. HW hace trap al SO, guardando el PC en pila ● 2. Guardar registros, y se llama al SO en modo kernel ● 3. SO descubre que página virtual se necesita (de un registro o de la última instrucción) ● 4. SO comprueba si la dirección es válida y permitida x protección. De no ser así se elimina o manda señal al proceso. Si es así, se busca un marco de página disponible o se usa el algoritmo de reemplazo ● 5. Si el marco está sucio, la página se planifica para transferir al HD, el proceso se pone en espera y se hace context switch hasta que se escriba la página (El marco se marca como “ocupado”)

Manejo de page fault en detalle ● 6. Cuando el marco está limpio, el SO planifica en HD para levantar la página requerida. Se hace CS de nuevo. ● 7. Cuando llega la página, se actualiza la tabla de páginas, y se marca al frame como normal ● 8. Se restablece el PC de la instrucción original ● 9. Se planifica al proceso fallido ● 10. Se recargan los registros, y se vuelve al modo usuario para continuar la ejecución

Cuestiones de implementación ● Respaldo de instrucción ● Cómo se sabe exactamente adonde volver en una instrucción que fue interrumpida? ●

Cuestiones de implementación ● Respaldo de instrucción ● MOV … es de 6 bytes, y el PC puede estar en el medio! (ej., falló un operando) ● Peor aún, algunos CPUs tienen “autoincremento”, que automáticamente cambian algunos registros ● Solución: (solo en algunos CPUs): guardar el PC, etc en otros registros especiales ● Pinning de memoria (ver libro): evita que sean eliminadas páginas relacionadas con IO ● Backing Store (ver libro): swap area

Segmentación ● Las tablas de páginas son “unidimensionales”. En cambio los segmentos dividen la memoria en varios espacions independientes de direccionamiento, y pueden crecer (hasta un máximo) ● Por ejemplo, el compilador gcc: tiene segmentos para contener el código textual del proceso, la tabla de símbolos, tabla de constantes y punto flotante, árbol sintáctico parseado, pila de llamadas, …)

Segmentación ● Un segmento es una entidad lógica disponible a los programadores ● En cambio, la paginación es algo interno del SO no expuesto a los usuarios ● La separación en segmentos tiene ventajas: ● 1. como generalmente cada segmento tiene datos del mismo tipo, se puede asignar protección por segmento (ej., permisos de sólo lectura y ejecución al código del proceso, y lectura y escritura (pero no ejecución) a los datos de un proceso ● 2. como las direcciones son por segmento, la compilación es + independiente (un proceso que no toca un segmento que no cambió no se tiene que recompilar

Segmentación ● Implementación de segmentación pura: genera fragmentación externa ● Mismo problema que memoria virtual sin paginación ● Implementacion de segmentación con paginación: Intel pentium ● Hay 16K segmentos por proceso (cada uno muy largo)

Comparación

Protección ● Diferentes procesos pueden acceder a segmentos en diferentes niveles de protección ● El intel pentium tiene 4 niveles del 0 al 3, ver grafico ● Procesos en niveles inferiores pueden acceder a niveles superiores pero no viceversa

Protección