Administración de Memoria

• Un gran arreglo de bytes
• Cada uno con su propia dirección

 mov %eax, 0x10001       ; a += 3
 add %eax, $0x3
 mov 0x10001, %eax

• Programa siempre se carga en la misma dirección
• Cada variable tiene la misma dirección en memoria en cada ejecución

 mov %eax, 0x10001       ; falla si a no está en 0x10001
 add %eax, $0x3
 mov 0x10001, %eax

• Variables no están siempre en la misma ubicación
• Requisito: relocalización de variables

 mov %eax, 0x20001       ; 0x20001 es memoria de C
 add %eax, $0x3
 mov 0x20001, %eax

• Un proceso, por error, podría leer memoria y modificar memoria de otro proceso
• Requisito: protección de memoria

• Caso (a). Un proceso único en memoria, de 16KB, cargado en 0.
• Caso (b). Otro proceso único en memoria, de 16KB, cargado en 0.
• Caso (c). Dos procesos de 16KB cargados en memoria, de manera contigua.

• Caso (b). Instrucción JMP 28 está OK si el proceso está cargado en 0.
• Caso (c). Si el proceso se carga en 16384JMP 28 por JMP 16412.
• ¿Cómo conseguirlo?
• Compilador podría generar: JMP 28+X
• Al cargar en memoria se determina que X es 16384, y se carga en memoria JMP 16412
• Ejecutar esto cada vez que se cargue

 #include <stdio.h>
 #include <stdlib.h>

 int b = 3;

 int main(int argc, char *argv[]) {
   int x=3;
   printf("Location of code   : %p\n", (void *)main);
   printf("Location of data   : %p\n", (void *)&b);
   printf("Location of heap   : %p\n", (void *)malloc(1));
   printf("Location of stack  : %p\n", (void *)&x);
   return x+b;
 }

• Proceso $A$ utiliza 16KB.
• code en 0-1023
• heap empieza en 1024, y crece
• stack empieza en 16383, y decrece
• Al cargarlo en memoria, el sistema operativo asigna Base: 4096, limit: 16384.
• Código de $A$ no es modificado
• Proceso $A$ pide la dirección virtual: 768
• MMU entrega la dirección física: 4864

• Requiere copiar memoria a otras direcciones
• Caro. No se hace.
• Mejor: asignar espacios de manera que no se necesite compactar

• Dirección virtual (lógica): $100$
• Está en segmento code
• Base + dirección $= 32768 + 100 = 32868$
• Dirección física: $32868$

• Dirección virtual (lógica): $4200$
• Está en segmento heap
• Base + dirección $= 34816 + 4200 = 39016$
• Dirección física: $39016$

Segmentation Fault!

• Dirección virtual (lógica): $4200$
• Está en segmento heap
• Offset dentro de heap: $4200-\mathbf{4096}=104$
• Base + offset $= 34816 + 104 = 34920$
• Dirección física: $34920$

• Dirección virtual (lógica): $16300$
• Segmento stack (segmento 3)
• Base + offset $= 28672 + 4012 = 32684$
• Dirección física: $32684$ ❌

• Dirección virtual (lógica): $16300$
• Segmento stack (segmento 3)
• Offset: complemento de 4096 (4KB, máximo offset). $4012-4096=-84$
• Base + offset $= 28672 - 84 = 28588$
• Dirección física: $28588$ ✔

• Menos fragmentación … pero sigue existiendo
• Difícil anticipar los tamaños de los segmentos

• Si la dirección está en el caché (TLB hit), se responde directamente
• Si la dirección no está en el caché (TLB miss), se lee desde la memoria y se actualiza TLB

 VPN = (virtualAddress & VPN_MASK) >> VPN_SHIFT;
 (Success, TLBEntry) = TLB_Lookup(VPN);
 if(Success) {         //TLB Hit: UN acceso a memoria
   if(!TLBEntry.protected) {
     offset = virtualAddress & OFFSET_MASK;
     physicalAddress = (TLBEntry.PFN << PFN_SHIFT) | offset;
     register = ReadMemory(physicalAddress);
   }
   else raise(PROTECTION_FAULT);
 }
 else {                //TLB Miss: DOS accesos a memoria
   PTEAddress = PageTableBaseRegister + (VPN * sizeof(PTE));
   PTE = ReadMemory(PTEAddress);
   if(!PTE.valid)          raise(SEG_FAULT);
   else if (PTE.protected) raise(PROTECTION_FAULT);
   else {
     TLB_Insert(VPN, PTE);
     Retry();
   }
 }

• 4 bit para offset. 4 bit para #página. 16 páginas.

int sum = 0;
for(i=0; i<10; i++)
  sum += a[i];

• Considerando sólo el acceso a a
• Sin TLB: 10 $\times$ (acceso tabla de páginas, acceso a[i])
• 20 accesos a memoria
• Con TLB: miss, hit, hit, miss, hit, hit, hit, miss, hit, hit
• 10 accesos a a[i], 3 accesos a tabla de páginas (miss)
• 13 accesos a memoria

int sum = 0;
for(i=0; i<10; i++)
  sum += a[i];

• Un acceso a memoria física $\approx 100\text{ns} = 10^{-7}\text{s}$
• Un acceso a TLB $\approx 1\text{ns} = 10^{-9}\text{s}$
• TLB Hit $\approx 101\text{ns}$
• TLB Miss $\approx 201\text{ns}$

• Sin TLB. 20 acc. a memoria. $2000\text{ns} = 2\times 10^{-6}\text{s}$
• Con TLB. 13 acc. a memoria, 10 acc. a TLB. $1310\text{ns} = 1.31 \times 10^{-6}\text{s}$
• Aceleración: $2000/1310 \approx 1.52$ veces más rápido.
• Tiempo promedio de acceso: $201\text{ns} \times 0.3 + 101\text{ns} \times 0.7 = 131\text{ns}$

TLB Hit Rate reales $\approx 99\%$

Localidad Espacial

int sum = 0;
for(i=0; i<1000; i++)
  sum += a[i];

• Luego de un miss, y guardar un PTE en TLB, vendrán muchos hit

Localidad Temporal

int sum = 0;
for(k=0; k<10; k++)
  for(i=0; i<1000; i++)
    sum += a[i];

• Una PTE recién guardada, volverá a ser usada pronto

• Proceso utiliza efectivamente: 4 páginas
• 12 entradas vacías ($75\%$) en tabla de páginas

• Tablas de páginas más pequeña 😃
• base (direcc. de tabla de páginas)
• limit (#paginas)
• Vuelve la fragmentación externa 😟

• Dirección virtual de 14-bit, páginas de $64\text{B}$.
• Esquema de 1 nivel: 256 PTEs.
• Memoria: $256 \times 4\text{B} = 1 \text{KB}$
• Esquema de 2 niveles: 16 PTEs en tabla principal, 16 PTEs en 16 tablas de 2do nivel
• Memoria: Al menos tabla principal + 1 tabla secundaria
• Memoria: $16 \times 4\text{B} + 16 \times 4\text{B} = 128{B}$

• En memoria se necesita la tabla de páginas del primer nivel (completa), y una tabla de cada nivel para poder resolver una dirección física
• Cada división puede tener distintos tamaños

• Indice es el frame. Una PTE por frame.
• Clave de búsqueda es $\langle$ pid, #page $\rangle$
• Consume menos memoria 😃
• Pero búsqueda es lenta (secuencial) 😞
• Alternativa: usar hashing

 VPN = (virtualAddress & VPN_MASK) >> VPN_SHIFT;
 (Success, TLBEntry) = TLB_Lookup(VPN);
 if(Success) {         //TLB Hit
   if(!TLBEntry.protected()) {
     offset = virtualAddress & OFFSET_MASK;
     physicalAddress = (TLBEntry.PFN << PFN_SHIFT) | offset;
     register = ReadMemory(physicalAddress);
   }
   else raise(PROTECTION_FAULT);
 }
 else {                //TLB Miss
   PTEAddress = PageTableBaseRegister + (VPN * sizeof(PTE));
   PTE = ReadMemory(PTEAddress);    // lectura tabla de paginas
   if(!PTE.valid)          raise(SEG_FAULT);
   else if (PTE.protected) raise(PROTECTION_FAULT);
   else if (!PTE.present)  raise(PAGE_FAULT);
   else {                  // pagina en memoria
     TLB_Insert(VPN, PTE);
     Retry();
   }
 }

 PFN = FindFreePhysicalPage();   // busca frame libre
 if(PFN == -1)                   '// no había frame libre :'(
   PFN = ReplacePage();          // rutina de reemplazo de página

 // Copia desde el disco a la memoria. Proceso queda "waiting on I/O"
 DiskRead(PTE.DiskAddress, PFN);

 // Actualiza tabla de páginas
 PTE.present = TRUE;
 PTE.PFN = PFN;

 // Vuelve a ejecutar la instrucción que generó el PAGE_FAULT 
 Retry(); 

• MIN hits: 6
• FIFO hits: 4

• MIN: 1 miss, Hit Rate $0.75$
• FIFO: 3 misses, Hit Rate $0.571$
• Similar a MIN 😃
• Implementable 😃
• ¿Eficientemente? 🤔

• Sin localidad todas las políticas que podemos implementar se comportan igual
• Con suficientes frames disponibles se llega a Hit Rate 1.
• Patrón poco común (pero posible)

• La cantidad de frames disponibles es como una cantidad de bloques de caché en memoria física
• OPT $\equiv$ MIN

• 80% de los 10000 accesos se hacen a un 20% de páginas (hot pages)
• 20% de los 10000 accesos se hacen al 80% de páginas restantes (cold pages)

• LRU mejor que FIFO y RANDOM
• Patrón más común

• La cantidad de frames disponibles es como una cantidad de bloques de caché en memoria física
• OPT $\equiv$ MIN

• FIFO y LRU eliminan las páginas más "antiguas"
• RANDOM se comporta mejor

• Peor caso para FIFO y LRU
• Patrón común en muchas aplicaciones
• Tamaño del conjunto de páginas usadas es crítico

• La cantidad de frames disponibles es como una cantidad de bloques de caché en memoria física
• OPT $\equiv$ MIN