Bueno, si la pregunta es simplemente "¿cuál es el tamaño de la tabla de páginas?" Independientemente de si cabe en la memoria física, la respuesta se puede calcular así:
Primera memoria física. Hay 512K páginas de memoria física (512M/1K). Esto requiere 19 bits para representar cada página. Agregue eso a los 4 bits de información contable y obtendrá 23 bits.
Ahora la memoria virtual. Con un espacio de direcciones de 38 bits y un tamaño de página de 10 bits (1K), necesita 2 entradas en su tabla de páginas.
Por lo tanto, 2 las entradas de la tabla de página a 23 bits cada una son 6,174,015,488 bits o 736M.
Ese es el tamaño máximo necesario para un subsistema VM de un nivel para cada proceso.
Ahora, obviamente, eso no va a funcionar si solo tienes 512M de RAM física, por lo que tienes un par de opciones.
Puede reducir el número de páginas físicas. Por ejemplo, solo permita que la mitad de la memoria esté sujeta a paginación, manteniendo la otra mitad residente en todo momento. Esto ahorrará un bit por entrada, no lo suficiente como para hacer una diferencia.
Aumente el tamaño de la página, si es posible. Una página de 1K en un espacio de direcciones de 38 bits es la razón de las tablas de páginas muy gruesas. Por ejemplo, creo que el '386, con su espacio de direcciones de 32 bits, usa páginas 4K. Eso daría como resultado un millón de entradas de tabla de páginas, mucho menos que los 260 millones requeridos aquí.
Ir a varios niveles. Un poco más avanzado, pero básicamente significa que las tablas de páginas en sí están sujetas a paginación. Debe mantener el primer nivel de tablas de páginas residente en la memoria física, pero el segundo nivel puede entrar y salir según sea necesario. Esto reducirá en gran medida los requisitos físicos pero a costa de la velocidad, ya que pueden ocurrir dos niveles de fallas de página para acceder a una página de proceso real (una para las tablas de paginación secundarias y otra para la página de proceso).
Veamos un poco más de cerca a la opción 3.
Si permitimos 32M para la tabla de paginación primario y dar a cada entrada de 4 bytes (32 bits: sólo el 23 son necesarios, pero podemos ronda para la eficiencia aquí), esto permitirá 8,388,608 páginas para la tabla de la página secundaria.
Dado que cada una de esas páginas de tabla de páginas secundarias tiene 1K de longitud (lo que nos permite almacenar 256 entradas de tabla de páginas secundarias a 4 bytes cada una), podemos direccionar un total de 2.147.483.648 páginas virtuales.
Esto permitiría que 8,192 totalmente cargados (es decir, utilizando todos sus espacios de direcciones de 28 bits) procesen para funcionar uno al lado del otro, suponiendo que tiene bastante espacio en disco para almacenar las páginas no residentes.
Ahora, obviamente, la tabla de paginación principal (y el subsistema VM, y probablemente una buena porción del resto del sistema operativo) tiene que permanecer residente en todo momento. No se le permite salir de una de las páginas principales, ya que puede necesitar esa página para traerla de vuelta a :-)
Pero ese es un costo residente de solo 32M de los 512M para la tabla de paginación principal, mucho mejor que el (como mínimo, para un proceso completamente cargado) de 736M.
2^28 entradas debido al tamaño de espacio virtual/tamaño de página. 4 bytes por entrada (28 bits para direccionar números vp, + 4 bits = 32 bits) 2^28 * 4 = 1024 MB, que es más grande que la memoria física. No tiene sentido, falto en la escuela. Esta es mi suposición, no la respuesta real. Gracias de antemano. –
No veo un requisito para que toda la tabla de páginas esté en la memoria física en ninguna parte de la pregunta. – paxdiablo
¿Por qué debería administrarse la memoria física y luego indicar que no hay direcciones de disco almacenadas en la tabla? Esto implicaría que solo necesita abordar los 512 MB de memoria física ... a menos que me equivoque. Gracias de nuevo. –