El uso de la paginación como mecanismo principal para implementar la memoria virtual puede generar una mayor sobrecarga de rendimiento. Debido a que se va a utilizar la paginación, el espacio de direcciones de la memoria debe dividirse en una gran cantidad de unidades de tamaño fijo (páginas), y la información de asignación de direcciones de estas unidades debe registrarse. Debido a que esta información de mapeo generalmente se almacena en la memoria física, al convertir direcciones virtuales, la lógica de paginación requiere un acceso adicional a la memoria. Cada vez que se recupera, carga o guarda explícitamente una instrucción, se requiere una lectura adicional de la memoria para obtener la información de conversión, que es inaceptablemente lenta. Por tanto, nos enfrentamos a los siguientes problemas:
Pregunta clave: cómo acelerar la traducción de direcciones
¿Cómo podemos acelerar la traducción de direcciones virtuales y evitar el acceso a memoria adicional tanto como sea posible? ¿Qué tipo de soporte de hardware se necesita? ¿Cómo debería admitirlo el sistema operativo?
Para hacer algo más rápido, el sistema operativo generalmente necesita ayuda. La ayuda a menudo proviene de viejos amigos de los sistemas operativos: el hardware. Necesitamos aumentar la llamada (por razones históricas [CP78]) memoria de búfer de derivación de traducción de direcciones (búfer de traducción-búsqueda adicional, TLB [CG68, C95]), que es la caché de hardware para la traducción de direcciones virtuales a físicas que ocurren con frecuencia. Por lo tanto, un mejor nombre sería caché de traducción de direcciones. Para cada acceso a la memoria, el hardware primero verifica el TLB para ver si existe el mapeo de conversión esperado, y si lo hay, la conversión se completa (pronto) sin acceder a la tabla de páginas (que tiene todos los mapeos de conversión). TLB aporta una gran mejora en el rendimiento, de hecho, hace posible la memoria virtual [C95].
19.1 Algoritmo básico de TLB
La Figura 19.1 muestra un marco general que ilustra cómo el hardware maneja la traducción de direcciones virtuales. Se supone que una tabla de página lineal simple (tabla de página lineal, es decir, la tabla de página es una matriz) y TLB administrada por hardware (TLB administrada por hardware, es decir, el hardware es responsable de muchos Responsabilidad del acceso a la tabla de páginas, habrá más explicación a continuación).
1 VPN = (VirtualAddress & VPN_MASK) >> SHIFT
2 (Success, TlbEntry) = TLB_Lookup(VPN)
3 if (Success == True) // TLB Hit
4 if (CanAccess(TlbEntry.ProtectBits) == True)
5 Offset = VirtualAddress & OFFSET_MASK
6 PhysAddr = (TlbEntry.PFN << SHIFT) | Offset
7 AccessMemory(PhysAddr)
8 else
9 RaiseException(PROTECTION_FAULT)
10 else // TLB Miss
11 PTEAddr = PTBR + (VPN * sizeof(PTE))
12 PTE = AccessMemory(PTEAddr)
13 if (PTE.Valid == False)
14 RaiseException(SEGMENTATION_FAULT)
15 else if (CanAccess(PTE.ProtectBits) == False)
16 RaiseException(PROTECTION_FAULT)
17 else
18 TLB_Insert(VPN, PTE.PFN, PTE.ProtectBits)
19 RetryInstruction()Figura 19.1 Algoritmo de flujo de control de TLB
El flujo general del algoritmo de hardware es el siguiente: primero extraiga el número de página (VPN) de la dirección virtual (consulte la Figura 19.1, línea 1) y luego verifique si la TLB tiene un mapeo de conversión para la VPN (línea 2). Si es así, tenemos un hit TLB, lo que significa que TLB tiene un mapa de conversión para esa página. ¡éxito! A continuación, podemos tomar el número de marco de página (PFN) de la entrada TLB relacionada, combinarlo con el desplazamiento en la dirección virtual original para formar la dirección física deseada (PA) y acceder a la memoria (líneas 5-7), asumiendo La comprobación de protección no falló (línea 4).
Si la CPU no encuentra el mapa de conversión en el TLB (TLB falla), tenemos trabajo por hacer. En este ejemplo, el hardware accede a la tabla de páginas para encontrar el mapa de traducción (líneas 11-12) y usa el mapa de traducción para actualizar el TLB (línea 18), asumiendo que la dirección virtual es válida y tenemos los derechos de acceso relevantes (línea 13, 15 líneas). La serie de operaciones anterior es costosa, principalmente porque se requieren referencias de memoria adicionales para acceder a la tabla de páginas (línea 12). Finalmente, cuando la actualización de TLB sea exitosa, el sistema volverá a intentar la instrucción. En este momento, existe esta asignación de conversión en la TLB y la referencia de memoria se procesa rápidamente.
TLB es similar a otros cachés, siempre que en circunstancias normales, la asignación de conversión estará en el caché (es decir, hit). Si es así, solo se agrega una pequeña cantidad de sobrecarga, porque la velocidad de acceso del diseño es muy rápida cerca del núcleo del procesador TLB. Si el TLB falla, traerá mucha sobrecarga de paginación. Se debe acceder a la tabla de páginas para encontrar el mapa de traducción, lo que da como resultado una referencia de memoria adicional (o más, si la tabla de páginas es más compleja). Si esto sucede con frecuencia, el programa se ralentizará significativamente. En comparación con la mayoría de las instrucciones de la CPU, el acceso a la memoria es caro y las fallas de TLB provocan más accesos a la memoria. Por lo tanto, esperamos evitar las fallas de TLB tanto como sea posible.
19.2 Ejemplo: acceder a una matriz
Para aclarar el funcionamiento de TLB, veamos un seguimiento de direcciones virtuales simple y veamos cómo TLB puede mejorar su rendimiento. En este ejemplo, suponga que hay una matriz de 10 enteros de 4 bytes y la dirección virtual inicial es 100. Suponga además que hay un pequeño espacio de direcciones virtuales de 8 bits con un tamaño de página de 16B. Podemos dividir la dirección virtual en una VPN de 4 bits (con 16 páginas de memoria virtual) y un desplazamiento de 4 bits (con 16 bytes en cada página).
Figura 19.2 Ejemplo: una matriz en un espacio de direcciones pequeño
La figura 19.2 muestra el diseño de esta matriz en 16 páginas de 16 bytes en el sistema. Como puede ver, el primer elemento (a [0]) de la matriz comienza en (VPN = 06, desplazamiento = 04) y solo se almacenan tres enteros de 4 bytes en esta página. La matriz continúa en la página siguiente (VPN = 07), que tiene los siguientes 4 elementos (a [3]… a [6]). Los últimos 3 elementos (a [7]… a [9]) de la matriz de 10 elementos se encuentran en la siguiente página del espacio de direcciones (VPN = 08).
Ahora considere un ciclo simple, accediendo a cada elemento en la matriz, similar al siguiente programa en C:
int sum = 0;
for (i = 0; i < 10; i++) {
sum += a[i];
}Para simplificar, pretendemos que el acceso a la memoria generado por el bucle es solo para el arreglo (ignorando las variables i y suma , y la instrucción en sí). Al acceder al primer elemento de la matriz (a [0]), la CPU verá cargada la dirección de memoria virtual 100. El hardware extrae la VPN (VPN = 06) de ella y luego la usa para verificar la TLB para encontrar una asignación de conversión válida. Suponga que esta es la primera vez que el programa accede a la matriz y el resultado es un error de TLB.
En la próxima visita a [1], estas son las buenas noticias: ¡éxito de TLB! Debido a que el segundo elemento de la matriz está después del primer elemento, están en la misma página. Debido a que ya visitamos esta página cuando visitamos el primer elemento de la matriz, el mapa de conversión de esta página se almacena en caché en el TLB. Entonces golpea con éxito. El acceso a un [2] también es exitoso (presione de nuevo) porque está en la misma página que un [0] y un [1].
Desafortunadamente, cuando el programa accede a [3], provocará un error de TLB. Pero nuevamente, los siguientes elementos (a [4]… a [6]) llegarán todos al TLB porque están en la misma página en la memoria.
Finalmente, el acceso a un [7] resultará en el último error de TLB. El sistema buscará nuevamente la tabla de páginas, determinará la ubicación de esta página virtual en la memoria física y actualizará el TLB en consecuencia. Las dos últimas visitas (a [8], a [9]) se beneficiaron de esta actualización de TLB. Cuando el hardware buscó su mapeo de conversión en el TLB, accedieron en ambas ocasiones.
Resumamos el comportamiento del TLB en estas 10 operaciones de acceso: fallar, acertar, acertar, fallar, acertar, acertar, acertar, fallar, acertar, acertar. Dividir el número de visitas por el número total de visitas da una tasa de visitas de TLB del 70%. Aunque esto no es muy alto (de hecho, queremos que la tasa de aciertos sea cercana al 100%), pero no es cero, y nos sorprendería si fuera cero. Aunque esta es la primera vez que el programa accede a la matriz, el TLB aún mejora el rendimiento gracias a la localidad espacial. Los elementos de la matriz se almacenan de cerca en varias páginas (es decir, están muy adyacentes en el espacio), por lo que solo el acceso al primer elemento de la página resultará en un error de TLB.
También preste atención al efecto del tamaño de la página en los resultados de este ejemplo. Si el tamaño de la página se duplica (32 bytes en lugar de 16), el acceso a la matriz encontrará menos errores. El tamaño de una página típica es generalmente de 4 KB. En este caso, el acceso intensivo basado en matrices logrará un excelente rendimiento de TLB, y cada acceso a la página solo encontrará una falla.
Hay un último punto sobre el rendimiento de TLB: si el programa accede a la matriz nuevamente poco después de este ciclo, veremos mejores resultados, asumiendo que el TLB es lo suficientemente grande como para almacenar en caché el mapeo de transformación requerido: golpe, golpe, golpe , Golpe, golpe, golpe, golpe, golpe, golpe. En este caso, debido a la localidad temporal, que vuelve a referirse al elemento de memoria en un corto período de tiempo, la tasa de aciertos de TLB será alta. Como otras cachés, el éxito de TLB se basa en la localidad espacial y temporal. Si un programa exhibe tal localidad (como lo hacen muchos programas), la tasa de aciertos de TLB puede ser alta.
Consejo: utilice la caché siempre que sea posible
El caché es una de las técnicas de mejora del rendimiento más básicas en los sistemas informáticos y se utiliza una y otra vez para hacer que "situaciones comunes sean más rápidas" [HP06]. La idea detrás del almacenamiento en caché de hardware es aprovechar la localidad de las instrucciones y las referencias de datos. Por lo general, existen dos tipos de localidad: localidad temporal y localidad espacial. La localidad temporal significa que pronto se podrá volver a acceder a la instrucción o elemento de datos a los que se haya accedido más recientemente. Piense en variables de ciclo o instrucciones en un ciclo, se accede a ellas repetidamente muchas veces. La localidad espacial significa que cuando un programa accede a la dirección de memoria x, puede acceder rápidamente a la memoria adyacente ax. Piense en atravesar algún tipo de matriz, accediendo a un elemento tras otro. Por supuesto, estas propiedades dependen de las características del programa, no una ley absoluta, sino más bien una regla de oro.
La caché de hardware, ya sean instrucciones, datos o traducción de direcciones (como TLB), aprovecha la ubicación para almacenar una copia de la memoria en una pequeña y rápida memoria en chip. El procesador puede verificar primero si hay una copia cercana en la caché, en lugar de tener que acceder a la memoria (lenta) para satisfacer la solicitud. Si existe, el procesador puede acceder a él muy rápidamente (por ejemplo, dentro de unos pocos relojes de CPU) y evitar perder mucho tiempo accediendo a la memoria (muchos nanosegundos).
Quizás se esté preguntando: dado que un caché como TLB es tan bueno, ¿por qué no hacer un caché más grande y almacenar todos los datos? Es una pena que aquí hayamos encontrado leyes más básicas, como las leyes de la física. Si desea almacenar en caché rápidamente, debe ser pequeño porque la velocidad de la luz y otras limitaciones físicas influirán. Los cachés grandes están destinados a ser lentos, por lo que no pueden lograr sus objetivos. Por lo tanto, solo podemos usar cachés pequeños y rápidos. La pregunta restante es cómo hacer un buen uso de la caché para mejorar el rendimiento.
19.3 Quién se ocupará de las faltas de TLB
Hay una pregunta que debemos responder: ¿quién se ocupará de las faltas de TLB? Puede haber dos respuestas: hardware o software (sistema operativo). El hardware anterior tenía un conjunto de instrucciones complejas (a veces llamado Computadora de conjunto de instrucciones complejas, CISC), y las personas que construían el hardware no confiaban en quienes trabajaban en el sistema operativo. Por lo tanto, el hardware es totalmente responsable de manejar fallas de TLB. Para hacer esto, el hardware debe conocer la ubicación exacta de la tabla de páginas en la memoria (a través del registro base de la tabla de páginas, usado en la línea 11 de la Figura 19.1) y el formato exacto de la tabla de páginas. Cuando ocurre un error, el hardware "recorrerá" la tabla de páginas, buscará la entrada correcta de la tabla de páginas, buscará el mapa de conversión deseado, actualizará el TLB con él y volverá a intentar la instrucción. Esta arquitectura "antigua" tiene TLB para la gestión de hardware. Un ejemplo es la arquitectura x86, que utiliza una tabla de páginas fija de varios niveles (consulte el Capítulo 20 para obtener más detalles). La tabla de páginas actual está indicada por el registro CR3 [I09 ].
Arquitecturas más modernas (por ejemplo, MIPS R10k [H93], SPARC v9 [WG00] de Sun, son computadoras con conjunto de instrucciones reducido, computadora con conjunto de instrucciones reducido, RISC), existen los llamados TLB administrados por software (TLB administrados por software) ). Cuando ocurre un error de TLB, el sistema de hardware lanzará una excepción (ver Figura 19.3, línea 11), que suspenderá el flujo de instrucciones actual, elevará el nivel de privilegios al modo kernel y saltará al controlador de trampas. A continuación, como habrás adivinado, este controlador de trampas es un fragmento de código del sistema operativo para manejar fallas de TLB. Cuando este código se esté ejecutando, buscará el mapa de conversión en la tabla de la página, luego actualizará el TLB con una instrucción especial "privilegiada" y regresará de la trampa. En este momento, el hardware volverá a intentar la instrucción (provocando un error de TLB).
1 VPN = (VirtualAddress & VPN_MASK) >> SHIFT
2 (Success, TlbEntry) = TLB_Lookup(VPN)
3 if (Success == True) // TLB Hit
4 if (CanAccess(TlbEntry.ProtectBits) == True)
5 Offset = VirtualAddress & OFFSET_MASK
6 PhysAddr = (TlbEntry.PFN << SHIFT) | Offset
7 Register = AccessMemory(PhysAddr)
8 else
9 RaiseException(PROTECTION_FAULT)
10 else // TLB Miss
11 RaiseException(TLB_MISS)Figura 19.3 Algoritmo de flujo de control de TLB (procesamiento del sistema operativo)
A continuación se comentan algunos detalles importantes. En primer lugar, la instrucción return from trap aquí es ligeramente diferente del return from trap mencionado anteriormente que sirve las llamadas al sistema. En el último caso, al regresar de la trampa debe continuar ejecutando la instrucción después de que el sistema operativo esté atrapado, al igual que al regresar de una llamada de función, continuará ejecutando la instrucción después de la llamada. En el primer caso, después de regresar de la captura perdida de TLB, el hardware debe continuar la ejecución de la instrucción que causó la captura. Por lo tanto, este reintento hará que la instrucción se ejecute nuevamente, pero esta vez llegará al TLB. Por lo tanto, de acuerdo con la causa de la trampa o excepción, el sistema debe guardar un contador de programa diferente cuando ingresa al kernel para que pueda continuar ejecutándose correctamente en el futuro.
En segundo lugar, al ejecutar el código de manipulación de errores de TLB, el sistema operativo debe tener mucho cuidado para evitar la recursividad infinita que provoca errores de TLB. Hay muchas soluciones, por ejemplo, puede colocar los controladores de trampas de errores TLB directamente en la memoria física [no están mapeados (sin mapear), sin traducción de direcciones]. O mantenga algunos elementos en el TLB, registre la traducción de direcciones permanente y válida y deje algunos de los bloques de ranuras de traducción de direcciones permanentes para el código de procesamiento mismo.
La principal ventaja del método de gestión de software es la flexibilidad: el sistema operativo puede utilizar cualquier estructura de datos para implementar la tabla de páginas sin cambiar el hardware. Otra ventaja es la sencillez. Se puede ver en el flujo de control de TLB (ver la línea 11 de la Figura 19.3, en comparación con las líneas 11 a 19 de la Figura 19.1) que el hardware no necesita hacer mucho trabajo en fallas, arroja excepciones y el manejo de fallas del sistema operativo El programa se encargará del resto.
Suplemento: RISC y CISC
En la década de 1980, hubo una acalorada discusión en el campo de la arquitectura de computadoras. Uno es el campo CISC, es decir, Computación de conjuntos de instrucciones complejas (Computación de conjuntos de instrucciones complejas), y el otro es RISC, es decir, Computación de conjuntos de instrucciones reducidos (Computación de conjuntos de instrucciones reducidos) [PS81]. El campo de RISC está representado por David Patterson de Berkeley y John Hennessy de Stanford (escribieron algunos libros muy famosos [HP06]), aunque John Cocke ganó más tarde el Premio Turing por sus primeros trabajos en RISC [CM00].
El conjunto de instrucciones CISC tiende a tener muchas instrucciones y cada instrucción es más poderosa. Por ejemplo, es posible que vea una copia de cadena que acepta dos punteros y una longitud, y copia algunos bytes del origen al destino. La idea detrás de CISC es que las instrucciones deben ser primitivas de alto nivel, lo que hace que el lenguaje ensamblador sea más fácil de usar y un código más compacto.
El conjunto de instrucciones RISC es todo lo contrario. El punto clave detrás de RISC es que el conjunto de instrucciones es en realidad el objetivo final del compilador, y todos los compiladores realmente requieren una pequeña cantidad de primitivas simples que se pueden usar para generar código de alto rendimiento. Por lo tanto, los defensores de RISC abogan por que las cosas innecesarias (especialmente el microcódigo) deben eliminarse del hardware tanto como sea posible, y las cosas restantes deben ser simples, unificadas y rápidas.
Los primeros chips RISC tuvieron un gran impacto porque eran significativamente más rápidos [BC91]. La gente escribió muchos artículos y algunas empresas relacionadas se establecieron una tras otra (como MIPS y Sun). Pero con el tiempo, los fabricantes de chips CISC como Intel han adoptado muchas de las ventajas de los chips RISC, como agregar etapas tempranas de canalización para convertir instrucciones complejas en algunas microinstrucciones, para que puedan ejecutarse como RISC. Estas innovaciones, junto con el aumento en el número de transistores en cada chip, han permitido a CISC seguir siendo competitivo. La controversia finalmente disminuyó y ahora ambos tipos de procesadores pueden funcionar muy rápido.
19.4 contenido TLB
Echemos un vistazo más de cerca al contenido de la TLB de hardware. Un TLB típico tiene 32, 64 o 128 elementos y es completamente asociativo. Básicamente, esto significa que puede existir un mapa de direcciones en cualquier lugar del TLB, y el hardware buscará el TLB en paralelo para encontrar el mapa de conversión deseado. El contenido de una entrada TLB puede tener el siguiente aspecto:
VPN ｜ PFN ｜ Otros bits
Tenga en cuenta que VPN y PFN existen en la TLB al mismo tiempo, porque una asignación de direcciones puede aparecer en cualquier lugar (en términos de hardware, TLB se denomina caché totalmente asociativa). El hardware busca estos elementos en paralelo para ver si coinciden.
Suplemento: ¡el bit efectivo de TLB! = El bit efectivo de la tabla de páginas
Un error común es confundir el bit efectivo del TLB y el bit efectivo de la tabla de páginas. En la tabla de páginas, si una entrada de la tabla de páginas (PTE) está marcada como no válida, significa que el proceso no ha solicitado la página para su uso y el programa que se ejecuta normalmente no debe acceder a la dirección. Cuando un programa intenta acceder a una página de este tipo, entrará en el sistema operativo y el sistema operativo terminará el proceso.
El bit efectivo de TLB es diferente, solo señala si el elemento TLB es una asignación de dirección válida. Por ejemplo, cuando se inicia el sistema, todas las entradas de TLB generalmente se inicializan a un estado no válido porque no hay un mapa de traducción de direcciones almacenado en caché aquí. Una vez que la memoria virtual está habilitada, cuando el programa comienza a ejecutarse y accede a su propia dirección virtual, la TLB se llenará lentamente, por lo que los elementos válidos llenarán rápidamente la TLB.
El bit válido TLB juega un papel importante en el cambio de contexto del sistema, que discutiremos más adelante. Al establecer todos los elementos de TLB como no válidos, el sistema puede garantizar que el proceso que se ejecutará no utilizará por error la asignación de traducción de direcciones virtuales a físicas del proceso anterior.
Más interesantes son los "otros bits". Por ejemplo, TLB suele tener un bit válido, que se utiliza para identificar si el elemento es un mapa de conversión válido. Suele haber algunos bits de protección para identificar si la página tiene derechos de acceso. Por ejemplo, las páginas de códigos se identifican como legibles y ejecutables, mientras que las páginas del montón se identifican como legibles y escribibles. Hay otros bits, incluido el identificador de espacio de direcciones (identificador de espacio de direcciones), bit sucio, etc. A continuación se presentará más información.
19.5 Manejo de TLB durante el cambio de contexto
Con TLB, al cambiar entre procesos (y, por lo tanto, el cambio de espacio de direcciones), enfrentará algunos problemas nuevos. Específicamente, la asignación de dirección virtual a física contenida en el TLB solo es válida para el proceso actual y no tiene significado para otros procesos. Por lo tanto, cuando ocurre un cambio de proceso, el hardware o el sistema operativo (o ambos) deben asegurarse de que el proceso que está a punto de ejecutarse no lea mal el mapa de direcciones del proceso anterior.
Para comprender mejor esta situación, veamos un ejemplo. Cuando se está ejecutando un proceso (P1), suponga que TLB almacena en caché la asignación de direcciones válida para él, es decir, la tabla de páginas de P1. Para este ejemplo, suponga que la página virtual número 10 de P1 está asignada a la trama física número 100.
En este ejemplo, suponga que hay otro proceso (P2) y el sistema operativo pronto decide realizar un cambio de contexto y ejecutar P2. Se asume aquí que la página virtual número 10 de P2 está mapeada con la trama física número 170. Si las asignaciones de direcciones de estos dos procesos están en la TLB, el contenido de la TLB se muestra en la Tabla 19.1.
En el TLB anterior, obviamente hay un problema: VPN 10 se convierte a PFN 100 (P1) y PFN 170 (P2), pero el hardware no puede decir qué elemento pertenece a qué proceso. Por lo tanto, todavía tenemos que trabajar un poco para que TLB admita de manera correcta y eficiente la virtualización en múltiples procesos. Por tanto, las preguntas clave son:
La pregunta clave: cómo administrar el contenido de TLB durante la conmutación de procesos
Si se produce un cambio de contexto entre procesos, la asignación de direcciones del proceso anterior en el TLB no tiene sentido para que se ejecute el proceso. ¿Qué debe hacer el hardware o el sistema operativo para solucionar este problema?
Hay algunas posibles soluciones a este problema. Un método es simplemente vaciar el TLB durante el cambio de contexto, de modo que el TLB quede vacío antes de que se ejecute el nuevo proceso. Si se trata de un sistema TLB de gestión de software, se puede realizar mediante una instrucción explícita (privilegiada) cuando se produce un cambio de contexto. Si es un TLB de administración de hardware, puede borrar el TLB cuando cambia el contenido del registro base de la tabla de páginas (tenga en cuenta que el sistema operativo debe cambiar el valor del registro base de la tabla de páginas (PTBR) durante el cambio de contexto). En cualquier caso, la operación de borrado establece todos los bits válidos (válidos) en 0, esencialmente borrando el TLB.
Borrar la TLB durante el cambio de contexto es una solución viable y el proceso ya no leerá la asignación de direcciones incorrecta. Sin embargo, hay una cierta sobrecarga: cada vez que se ejecuta un proceso, cuando accede a los datos y a las páginas de códigos, se desencadena un error de TLB. Si el sistema operativo cambia los procesos con frecuencia, esta sobrecarga será alta.
Para reducir esta sobrecarga, algunos sistemas han agregado soporte de hardware para lograr el intercambio de TLB de conmutación entre contextos. Por ejemplo, algunos sistemas agregan un identificador de espacio de direcciones (ASID) al TLB. Puede pensar en ASID como un identificador de proceso (PID), pero generalmente tiene menos bits que PID (PID generalmente es de 32 bits y ASID es generalmente de 8 bits).
Si todavía tomamos el TLB anterior como ejemplo y agregamos el ASID, está claro que diferentes procesos pueden compartir el TLB: siempre que el campo ASID se use para distinguir el mapeo de direcciones indistinguibles. La Tabla 19.2 muestra el TLB después de agregar el campo ASID.
Tabla 19.2 TLB después de agregar el campo ASID
Por lo tanto, con el identificador de espacio de direcciones, la TLB puede almacenar en caché las asignaciones de espacios de direcciones de diferentes procesos al mismo tiempo sin ningún conflicto. Por supuesto, el hardware también necesita saber qué proceso se está ejecutando actualmente para realizar la traducción de direcciones, por lo que el sistema operativo debe establecer un determinado registro privilegiado como ASID del proceso actual durante el cambio de contexto.
Además, es posible que hayas pensado en otra situación, dos de los TLB son muy similares. En la Tabla 19.3, dos elementos que pertenecen a dos procesos diferentes apuntan dos VPN diferentes a la misma página física.
Esto puede suceder si dos procesos comparten la misma página física (por ejemplo, una página de un segmento de código). En el ejemplo anterior, el proceso P1 y el proceso P2 comparten la página física 101, pero P1 asigna su página virtual 10 a esta página física y P2 asigna su página virtual 50 a la página física. Las páginas de códigos compartidas (en bibliotecas binarias o compartidas) son útiles porque reducen el uso de páginas físicas, lo que reduce la sobrecarga de memoria.
19.6 Estrategia de reemplazo de TLB
TLB, al igual que otros cachés, tiene otro problema a considerar, es decir, el reemplazo de caché. Específicamente, cuando se inserta un elemento nuevo en el TLB, se reemplaza (se reemplaza) un elemento antiguo, por lo que la pregunta es: ¿cuál debería reemplazarse?
Pregunta clave: cómo diseñar una estrategia de reemplazo de TLB
Al agregar un nuevo elemento a la TLB, ¿qué elemento antiguo debe reemplazarse? El objetivo es, por supuesto, reducir la tasa de fallos de TLB (o aumentar la tasa de aciertos), mejorando así el rendimiento.
Estudiaremos esta estrategia en detalle cuando analicemos el tema del intercambio de páginas al disco. A continuación, señalamos brevemente algunas estrategias típicas. Una estrategia común es reemplazar los elementos menos usados recientemente (LRU). LRU intenta aprovechar la localidad en el flujo de referencia de memoria, asumiendo que los elementos que no se han utilizado recientemente pueden ser buenos candidatos para el intercambio. Otra estrategia típica es la estrategia aleatoria (aleatoria), es decir, seleccionar aleatoriamente un artículo para intercambiar. Esta estrategia es simple y puede evitar una situación extrema. Por ejemplo, un programa accede a n +1 páginas en un bucle , pero el tamaño de TLB solo puede almacenar n páginas. En este momento, la estrategia LRU aparentemente "razonable" se comportará de manera irrazonable, porque cada acceso a la memoria desencadenará una falla TLB, y la estrategia aleatoria es mucho mejor en este caso.
19.7 Entradas TLB del sistema actual
Finalmente, miramos brevemente el TLB real. Este ejemplo proviene de MIPS R4000 [H93], que es un sistema moderno que usa software para administrar TLB. La figura 19.4 muestra un término TLB MIPS ligeramente simplificado.
Figura 19.4 Elementos TLB de MIPS
MIPS R4000 admite un espacio de direcciones de 32 bits con un tamaño de página de 4 KB. Entonces, en una dirección virtual típica, espere ver una VPN de 20 bits y un desplazamiento de 12 bits. Sin embargo, como puede ver en la TLB, solo hay VPN de 19 bits. De hecho, la dirección de usuario solo ocupa la mitad del espacio de direcciones (el resto está reservado para el kernel), por lo que solo se requiere una VPN de 19 bits. La VPN se convierte en un número de fotograma físico (PFN) máximo de 24 bits, por lo que puede admitir sistemas con hasta 64 GB de memoria física (224 páginas de memoria de 4 KB).
MIPS TLB también tiene algunos marcadores interesantes. Por ejemplo, el bit global (Global, G) se utiliza para indicar si esta página es compartida globalmente por todos los procesos. Por tanto, si la posición global es 1, se ignora el ASID. También hemos visto el ASID de 8 bits, que utiliza el sistema operativo para distinguir el espacio de proceso (como se describe anteriormente). Aquí hay una pregunta: ¿qué pasa si el número de procesos en ejecución supera los 256 (28)? Finalmente, vemos 3 bits de coherencia (Coherence, C), que determinan cómo el hardware almacena en caché la página (uno de los cuales está fuera del alcance de este libro); el bit sucio (sucio) indica si la página está escrita con datos nuevos ( El uso se presentará más adelante); el bit válido (válido) le dice al hardware si la asignación de direcciones del elemento es válida. También hay un campo de máscara de página, que no se muestra en la Figura 19.4, para admitir diferentes tamaños de página. Más adelante, explicaré por qué una página más grande puede resultar útil. Finalmente, algunos de los 64 bits no se utilizan (la parte gris en la Figura 19.4).
MIPS TLB generalmente tiene 32 elementos o 64 elementos, la mayoría de los cuales se proporcionan para procesos de usuario y una pequeña parte está reservada para sistemas operativos. El sistema operativo puede configurar un registro monitoreado para decirle al hardware cuántas ranuras TLB necesita reservar para sí mismo. Estas asignaciones de conversión reservadas son utilizadas por el sistema operativo para el código y los datos que utiliza en momentos críticos. En estos momentos, las fallas de TLB pueden causar problemas (por ejemplo, en los controladores de fallas de TLB).
Dado que la TLB de MIPS se gestiona mediante software, el sistema debe proporcionar algunas instrucciones para actualizar la TLB. MIPS proporciona cuatro de estas instrucciones: TLBP, que se utiliza para encontrar si el mapeo de conversión especificado está en el TLB; TLBR, que se utiliza para leer el contenido del TLB en el registro especificado; TLBWI, que se utiliza para reemplazar el elemento TLB especificado; TLBWR , Se utiliza para reemplazar aleatoriamente un elemento TLB. El sistema operativo puede utilizar estas instrucciones para administrar el contenido de la TLB. Por supuesto, estas instrucciones son instrucciones privilegiadas, lo cual es fundamental. Si el programa de usuario puede modificar el contenido de la TLB arbitrariamente, puede imaginar las cosas terribles que sucederán.
Consejo: la RAM no siempre es RAM (Ley de Culler)
La memoria de acceso aleatorio (RAM) implica que puede acceder a cualquier parte de la RAM tan rápido. Aunque generalmente es correcto pensar en la RAM de esta manera, debido a las funciones del hardware / sistema operativo como TLB, acceder a algunas páginas de memoria es costoso, especialmente las páginas que no están almacenadas en caché por TLB. Por lo tanto, es mejor recordar este truco de implementación: la RAM no siempre es RAM. A veces, el acceso aleatorio al espacio de direcciones, especialmente las páginas que no están almacenadas en caché por la TLB, puede causar graves pérdidas de rendimiento. Debido a que uno de mis mentores, David Culler, solía señalar que TLB es la fuente de muchos problemas de desempeño, le pusimos su nombre a esta ley: Ley de Culler.
Este artículo está extraído de "Introducción a los sistemas operativos"
Este libro se centra en los tres conceptos principales de virtualización, concurrencia y persistencia, e introduce los componentes principales de todos los sistemas modernos (incluida la programación, la administración de memoria virtual, los subsistemas de disco y E / S y los sistemas de archivos). El libro consta de 50 capítulos, divididos en 3 partes, que tratan sobre virtualización, concurrencia y persistencia. El autor presenta los conceptos temáticos introducidos en forma de diálogo, y también se incluye la escritura ingeniosa y humorística, tratando de ayudar a los lectores a comprender los principios de virtualización, concurrencia y persistencia en los sistemas operativos.
El contenido de este libro es completo y proporciona un código real y ejecutable (no un pseudocódigo), y también proporciona los ejercicios correspondientes, lo cual es muy adecuado para que los profesores de especializaciones relacionadas en colegios y universidades lleven a cabo la enseñanza y los estudiantes universitarios realicen el autoaprendizaje.
Este libro tiene las siguientes características:
● El tema es prominente y rodea de cerca los tres elementos temáticos principales del sistema operativo: virtualización, concurrencia y persistencia.
● Presente los antecedentes en la forma del diálogo, haga preguntas, explique los principios e inspire la práctica.
● Contiene muchos "suplementos" y "sugerencias" para ampliar el conocimiento de los lectores y aumentar el interés.
● Utilice código real en lugar de pseudocódigo para permitir que los lectores tengan una comprensión más profunda y completa del sistema operativo.
● Proporcione muchos métodos de aprendizaje, como asignaciones, simulaciones y proyectos, para animar a los lectores a practicar.
● Dotar a los profesores de recursos didácticos auxiliares.