El tamaño de página de memoria predeterminado del kernel de Linux en la arquitectura x86 era de 4 KB, me pregunto cómo se calculó eso, y por qué?¿Por qué es el tamaño de página de Linux (x86) 4 KB, cómo se calcula eso?
El tamaño de página predeterminado se fija según lo que admite la MMU (unidad de gestión de memoria) de la CPU. En x86 de 32 bits en modo protegido admite dos tipos de páginas:
No todos los procesadores x86 de apoyo grande páginas. Uno necesita tener una CPU con capacidades de extensión de tamaño de página (PSE). Esto excluye los procesadores pre-Pentium. Prácticamente todas las CPU x86 de la generación actual lo implementan.
4 KiB es una granularidad de página muy popuplar en otras arquitecturas también. Se podría argumentar que este tamaño proviene de la división de una dirección virutal de 32 bits en dos índices de 10 bits en directorios/tablas de página y los 12 bits restantes dan el tamaño de página de 4 KB.
Tengo este del artículo de Wikipedia y cito:
Tamaño de la página se determina generalmente por la arquitectura del procesador
Salida del artículo siguiente:
That depends on the processor architecture.
El tamaño de página predeterminado es de 4 KB en muchas arquitecturas. En general, se puede aumentar (a veces mucho, como AMD64 de 1 GB) al cambiar al modo huge page. Esto permite que la tabla de páginas sea más pequeña, lo que puede mejorar el rendimiento.
El diseño de 4 KB de tamaño de página normal de la arquitectura de 32 bits es realmente muy interesante :)
y me gustaría añadir una respuesta adicional a demostrar por qué es razonable.
x86 utiliza '2-pass' para traducir direcciones de memoria virtual en direcciones de memoria física.
Supongamos que tanto el directorio de página como la tabla de página contienen 
entradas, y el tamaño de página es 
bytes. Para hacer un uso completo de la dirección de 
, tenemos:
Cada entrada de directorio de página/tabla consume 4 bytes (32 bits), por tanto:
De este modo y = 12, y el tamaño de página en bytes será = 
= 4KB.
Y ¿qué pasa con '1-pass'? Esto es interesante porque lógicamente podemos usar una única tabla de página para la búsqueda de direcciones.
Supongamos que el directorio de la página contiene 
entradas, cada una asignando una dirección a la página correspondiente, y el tamaño de página es 
bytes.
Una vez más, para hacer un uso completo de direcciones, necesitamos:
Y:
obtenemos y = 17, y el tamaño de página es = 
= 128KB.
De todos modos, esto funciona "lógicamente". Si presentamos TLB, un tamaño tan grande de memoria será un diaster: las páginas de memoria serán difíciles de colocar en TLB, y el diseño no será eficiente.
También podríamos argumentar que, en la versión '2-pass', el directorio de páginas y la tabla de páginas pueden tener diferentes tamaños. Sin embargo, esto significa que utilizaremos un directorio de páginas más grande, que ocupará más de una página de memoria. Lamentablemente, cada vez que se genera un nuevo proceso de usuario, para su propio directorio de páginas, el sistema operativo debe asignar páginas sucesivas, lo que no es elegante por diseño.
La terminología normal es "tabla de página de 2 niveles", no "2 pasos". p.ej. [x86-64 usa una tabla de páginas de 4 niveles] (https://stackoverflow.com/questions/46509152/why-in-64bit-the-virtual-address-are-4-bits-short-48bit-long-compared -with-the) (aún con 4k páginas regulares, pero páginas enormes son 2M o 1G en vez de 4M.) –
Su sección de tabla de páginas de 1 nivel hace una suposición innecesaria: La tabla de páginas en sí no * tiene * de 1 página en tamaño. Podría tener páginas más pequeñas (y una tabla de página plana aún más gigantesca).Lo que apesta alrededor de 1 nivel es el tamaño de la tabla de páginas: un proceso con solo una pequeña cantidad de memoria asignada puede tener un árbol disperso con solo un par de tablas de páginas de nivel inferior. TLB no es un problema en absoluto; cada TLB contiene la traducción completa de todos los niveles de la tabla de páginas, por lo que las páginas más grandes significan menos bits de página, lo que significa un CAM más pequeño. Y menos entradas de TLB cubren más memoria. –
Agrego esta respuesta/comentario porque el cálculo de sleepsort es muy interesante, tengo que agregarlo a mi página web (mencionando la fuente del curso). Una respuesta (posible) a la pregunta de cómo se puede calcular el tamaño de página mediante programación se puede encontrar en here. La forma en que se calcula como se menciona por sleepsort es muy interesante. Hice lo mismo para x86_64 y el resultado no fue el esperado. Sin embargo, leyendo más en memory management x86_64 encontré que para 64 bits de inteligencia, 16 bits no se utilizan, deje 48 bits para que podamos calcular. 9 bits para las ramas del árbol de memoria, cada rama otros 9 bits, aquí en otros 9 para las ramas y finalmente 9 bits para las hojas de la última rama. Entonces 48 - 36 = 12 bits para cada dirección en la página de memoria. 2^12 = 4096 como se mencionó antes en la cabina. Me pregunto cuántos pase esta arquitectura es, 3 o 4 (si alguien puede explicar que) siguiente cálculo de sleepsort:
2^x * 2^x * 2^x * 2^x * 2^y = 2^48
4x + y = 48
this time we have 8 bytes for each address (8 bytes * 8 bits/byte = 64 bits)
2^y/2^3 = 2^x
y - 3 = x
filled in in previous equation:
4(y - 3) + y = 48
4y - 12 + y = 48
5y = 60
y = 12
because 2^y represents the pagesize, the size = 2^12 = 4096 bytes
me dejo con la pregunta "¿qué pasa con esos enormes páginas en Linux"?
Las páginas grandes de 4M son solo para el modo x86 de 32 bits. 64-bit x86 usa 2M o 1G páginas enormes, porque el formato de tabla de páginas de 4 niveles usa 9 bits por nivel. https://stackoverflow.com/questions/46509152/why-in-64bit-the-virtual-address-are-4-bits-short-48bit-long-compared-with-the. (El tamaño de página no grande sigue siendo 4k en modo largo, por lo que el caché L1DTLB y L1D aún puede funcionar básicamente igual, entre otras razones). –
@ PeterCordes, gracias por su comentario. De hecho, me he dirigido al modo de 32 bits y eso es lo que normalmente denotar por x86. –