Entrevista de sistemas operativos: ¿cómo funcionan la memoria virtual y los fallos de página?

Pregunta y escenario aplicable

Un servicio de Linux utiliza mmap para mapear un índice de solo lectura de 20 GiB al iniciar, y luego ejecuta un fork de 8 procesos worker. El monitoreo muestra:

• la memoria virtual de cada proceso crece aproximadamente 20 GiB poco después de crearse el mapeo;
• el RSS no crece en la misma cantidad de inmediato, sino que aumenta a medida que las consultas acceden a más regiones del índice;
• las primeras peticiones tras un arranque en frío tienen mayor latencia y más fallos de página mayores;
• repetir las mismas consultas es más rápido y produce muchos menos fallos mayores.

Explique cómo las direcciones virtuales se convierten en direcciones físicas, en qué se diferencia un fallo de TLB (TLB miss) de un fallo de página (page fault), qué significan los fallos de página menores y mayores en Linux, y por qué sumar el RSS de los 8 workers puede sobrestimar el consumo de memoria física. Finalice con un método para verificar el cuello de botella y reducir la latencia de arranque en frío.

Esta pregunta es adecuada para entrevistas de backend, infraestructura, software de sistemas, SRE e ingeniería de rendimiento. El mapeo de 20 GiB, los 8 workers y el tamaño de página de 4 KiB utilizados a continuación son supuestos hipotéticos para el ejercicio, no mediciones de producción de las fuentes. El índice es un mapeo de archivo de solo lectura. La memoria anónima, los mapeos privados de escritura, los límites de memoria en contenedores y los sistemas en tiempo real cambiarían la investigación.

Qué evalúa el entrevistador

La primera señal es si el candidato separa cuatro capas. Un espacio de direcciones virtuales describe lo que un proceso puede direccionar. Las tablas de páginas almacenan traducciones y permisos. El TLB almacena en caché las traducciones recientes. Las páginas físicas contienen los datos actualmente residentes en RAM. Una respuesta básica dice que la memoria virtual puede exceder la memoria física; una respuesta sólida recorre una instrucción de carga (load), incluyendo un acierto en TLB, un recorrido de tablas de páginas (page-table walk), un fallo reparable y un acceso ilegal.

La segunda señal es reconocer que un fallo de TLB no es un fallo de página. Si la traducción no está en el TLB pero la entrada de la tabla de páginas es válida y residente, el procesador puede completar el recorrido de la tabla de páginas y llenar el TLB. Un fallo de página ocurre cuando el estado actual de la tabla de páginas no puede satisfacer el acceso, como una página no residente, una primera escritura que requiere copy-on-write o una violación de permisos.

La tercera señal es la interpretación correcta de los contadores de Linux. Un fallo menor no requiere E/S de disco. La página puede estar ya en la caché de páginas (page cache) pero no mapeada en este proceso, o el kernel puede estar asignando una página anónima o completando un copy-on-write. Un fallo mayor requiere E/S de disco. Puede cargar memoria anónima enviada al swap, pero también puede leer un mapeo respaldado por archivo ausente de la page cache. Por lo tanto, afirmar que «fallo mayor significa swap» es incorrecto.

Finalmente, el entrevistador busca un ciclo basado en evidencias. Una respuesta sólida alinea la latencia de las peticiones, los deltas de fallos, la residencia de páginas de archivo, la E/S en dispositivos de bloques, el RSS/PSS y la presión de memoria en la misma ventana de tiempo antes de elegir un precalentamiento (warm-up), una disposición de índice distinta, sugerencias de acceso al kernel o un working set más pequeño.

Preguntas aclaratorias antes de responder

• ¿Se trata de memoria respaldada por archivo o anónima, y el mapeo es MAP_SHARED o MAP_PRIVATE? Las páginas de archivo de solo lectura pueden compartirse a través de la page cache. Las páginas privadas de escritura pueden volverse específicas de cada proceso tras un copy-on-write.
• ¿De qué tamaño es el working set caliente y el acceso es secuencial o aleatorio? Si el 95% de las peticiones acceden solo a una región caliente de 2 GiB, precalentar los 20 GiB completos añade presión al arranque y a la memoria. Los escaneos secuenciales y las búsquedas aleatorias también requieren diferentes decisiones de lectura anticipada (read-ahead).
• ¿El mmap ocurre antes o después del fork? Ambos enfoques pueden mapear el mismo archivo, pero mapear antes de fork facilita que los workers hereden una única configuración. Cada proceso sigue manteniendo sus propias tablas de páginas y su estado del TLB.
• ¿Aumentan los fallos mayores al mismo tiempo que las lecturas de bloques y la latencia de cola? Dicha correlación es indispensable antes de atribuir la mayor parte del costo de arranque en frío a la paginación por demanda. La saturación de CPU, bloqueos (locks), almacenamiento remoto e inicialización de índices pueden coexistir.
• ¿Está habilitado el swap, existen límites de memoria en cgroups o contenedores y ha ocurrido alguna liberación de memoria (reclaim) recientemente? Los mapeos respaldados por archivos pueden generar fallos mayores sin swap. La presión de memoria puede expulsar páginas de archivo cargadas recientemente y provocar fallos repetidos.
• ¿Cuál es el SLO de disponibilidad para tráfico (readiness)? Un servicio que debe aceptar tráfico en 10 segundos no puede escanear a ciegas 20 GiB. Un presupuesto de inicialización más amplio puede permitir transferir fallos seleccionados antes del estado de readiness.

Estructura de respuesta en 30 segundos

«mmap crea un rango virtual respaldado por archivo sin leer los 20 GiB completos, por lo que VIRT salta de inmediato mientras que RSS crece con el primer acceso. La CPU consulta el TLB; un fallo de TLB se resuelve con un recorrido de la tabla de páginas cuando la entrada es válida y residente, mientras que un fallo de página necesita reparación por parte del kernel. Los fallos menores en Linux no requieren E/S de disco; los fallos mayores sí, por lo que las páginas de archivo frías incrementan los fallos mayores y la latencia de peticiones hasta que la page cache se calienta. Las páginas de solo lectura pueden compartirse entre 8 workers, por lo que la suma del RSS las cuenta por duplicado; use PSS. Correlacione los deltas de fallos, RssFile/PSS, la E/S de lectura y el p99, y luego precaliente solo las páginas calientes o evalúe madvise y MAP_POPULATE dentro del presupuesto de arranque».

Este marco explica las observaciones, separa las dos confusiones comunes y concluye con una medición y una decisión. Una respuesta completa también debe explicar la ruta del fallo y las condiciones bajo las cuales falla cada optimización.

Análisis detallado paso a paso

Paso 1: Separar espacio de direcciones, mapeo y páginas residentes

La memoria virtual proporciona a cada proceso un espacio de direcciones independiente. Una dirección virtual puede considerarse como un número de página virtual más un desplazamiento (offset). Las tablas de páginas mapean números de páginas virtuales a marcos de páginas físicas y almacenan estados o permisos como presente, de escritura y ejecutable. Las tablas de páginas multinivel asignan niveles inferiores solo para los rangos de direcciones utilizados, evitando una tabla lineal masiva para un espacio de direcciones disperso.

El resultado inmediato de mapear un archivo de 20 GiB es un área de memoria virtual de 20 GiB. El mapeo describe cómo ese rango de direcciones se corresponde con el archivo; no requiere que el kernel lea el archivo completo de inmediato. Por consiguiente:

• VIRT o VmSize pueden aumentar aproximadamente 20 GiB a la vez;
• las páginas de archivo no accedidas no necesitan estar en RAM;
• cuando una consulta lee una página por primera vez, el kernel puede cargarla en la page cache e instalar un mapeo en la tabla de páginas;
• RSS cuenta la porción residente, por lo que crece a medida que se toca el working set.

Asumiendo páginas de 4 KiB, acceder a todo el mapeo de 20 GiB implica tocar:

20 × 2^30 ÷ 4096 = 5,242,880 páginas.

Ese cálculo demuestra por qué «calentar todo» no es gratis. Si solo una pequeña región está caliente, escanear más de 5.24 millones de páginas carga datos de bajo valor en memoria y puede expulsar otras entradas de caché útiles.

Paso 2: Recorrer el TLB y las tablas de páginas

Cuando la CPU ejecuta una carga (load), almacenamiento (store) o recuperación de instrucción (fetch), debe traducir una dirección virtual:

1. buscar el número de página virtual en el TLB;
2. en caso de acierto en TLB (hit), obtener el marco físico y combinarlo con el offset;
3. en caso de fallo de TLB (miss), permitir que el hardware o el sistema operativo consulten la tabla de páginas;
4. si la entrada es válida, permitida y residente, almacenar en caché la traducción en el TLB y reintentar o continuar;
5. si la entrada actual no puede satisfacer el acceso, entrar en la ruta de fallo de página.

Un fallo de TLB significa «la caché de traducciones no tuvo acierto». Un fallo de página significa «el estado actual de la tabla de páginas no puede completar este acceso». El primero puede añadir únicamente un recorrido de la tabla de páginas. El segundo ingresa al kernel para determinar si el acceso es legal y reparable. Confundir ambos conceptos lleva a afirmaciones incorrectas sobre qué problemas pueden solucionar las huge pages, la prebúsqueda o un almacenamiento más rápido.

Paso 3: Dividir los fallos de página en casos reparables y fatales

Un fallo de página es una excepción, no necesariamente un error de programa. El kernel primero verifica la dirección y los permisos:

• Página de archivo legal pero no residente: lee la página del archivo o mapea una página existente de la page cache.
• Primer acceso legal a memoria anónima: una primera lectura puede mapear la zero page compartida, mientras que una primera escritura asigna una página física real.
• Primera escritura tras fork en una página privada: ejecuta copy-on-write y otorga al proceso escritor una copia privada.
• Dirección no mapeada o permiso prohibido: si el acceso no se puede reparar, envía una señal como SIGSEGV.

Tras reparar un fallo, el kernel actualiza la tabla de páginas y reintenta la instrucción que falló. Si se requiere E/S de almacenamiento, el proceso se bloquea mientras espera y el planificador (scheduler) puede ejecutar otra tarea. Esa ruta de bloqueo es la razón por la cual los fallos mayores pueden incrementar directamente la latencia por petición.

Paso 4: Interpretar correctamente los fallos menores y mayores

Linux utiliza una distinción operativa: ¿el manejo del fallo requirió E/S de disco?

• Fallo menor: no se requirió E/S de disco. La página de archivo puede estar ya en la page cache pero no mapeada aún en este proceso. La memoria anónima puede materializarse por demanda, o el copy-on-write puede completarse en memoria.
• Fallo mayor: se requirió E/S de disco. En este escenario, la primera consulta en frío puede acceder a una página del índice ausente de la page cache, obligando al kernel a leerla desde el archivo del índice.

Dos contraejemplos fortalecen la respuesta:

1. Un fallo mayor no requiere swap. Un mapeo respaldado por archivo en frío puede requerir E/S de almacenamiento.
2. Un fallo menor no es gratuito. Aún puede ingresar al kernel, asignar una página, actualizar tablas de páginas y reintentar una instrucción; simplemente evita la ruta más lenta de E/S de disco.

Paso 5: Explicar por qué el RSS sumado es engañoso

Cuando 8 workers leen el mismo mapeo de archivo de solo lectura, las páginas del archivo subyacente pueden compartirse mediante la page cache. El RSS de cada proceso incluye las páginas residentes mapeadas en dicho proceso, por lo que la misma página física puede aparecer en múltiples valores de RSS. Sumar los 8 valores de RSS cuenta doblemente las páginas compartidas.

Como mínimo, distinga:

• VmSize: tamaño del espacio de direcciones virtuales;
• VmRSS: todas las páginas residentes para este proceso;
• RssFile: mapeos respaldados por archivo residentes;
• RssAnon: memoria anónima residente;
• PSS: páginas compartidas divididas proporcionalmente entre los procesos que las mapean;
• VmPTE: memoria consumida por las entradas de la tabla de páginas;
• VmSwap: datos privados anónimos en swap para el proceso, no una vista completa de mapeos de archivo.

/proc/<pid>/smaps_rollup proporciona RSS y PSS agregados para todos los mapeos de un proceso. Al estimar la huella física atribuible de los 8 workers, la suma de PSS suele ser más útil que la suma de RSS, aunque la competencia por la page cache del sistema y los procesos no relacionados sigan importando.

Paso 6: Verificar el cuello de botella con observaciones reproducibles

Construya una línea temporal única en lugar de extraer conclusiones de una captura aislada de top. En un entorno de pruebas de Linux, recopile:

grep -E 'VmSize|VmRSS|RssAnon|RssFile|VmPTE|VmSwap' /proc/$pid/status
cat /proc/$pid/smaps_rollup
perf stat -e page-faults,minor-faults,major-faults -p "$pid" -- sleep 30

Luego ejecute exactamente el mismo conjunto de consultas dos veces:

1. tras un arranque en frío, registre p50, p95 y p99 de las peticiones, deltas de fallos, lecturas de bloques y RSS/PSS;
2. repita de inmediato con los mismos datos, concurrencia y ruta de código;
3. si los fallos mayores, la E/S de lectura y la latencia de cola son elevados en la primera ejecución y mucho menores en la segunda, la carga por demanda de páginas de archivo es una explicación primaria sólida;
4. si los fallos mayores son escasos mientras la latencia sigue alta, inspeccione CPU, bloqueos, llamadas remotas e inicialización interna del índice;
5. repita bajo presión controlada de memoria para verificar si la liberación de páginas calientes vuelve a generar picos de latencia.

Los contadores de fallos son acumulativos, por lo que debe comparar los deltas dentro de la misma ventana de tiempo en lugar de los totales históricos. Mida los workers por separado para que los fallos de un escáner en segundo plano no se atribuyan erróneamente a peticiones en línea.

Paso 7: Elegir una optimización basada en el working set y el SLO

La opción más agresiva no es automáticamente la mejor:

1. Mantener paginación por demanda: arranque más rápido y memoria proporcional al working set real. Se adapta a cargas de trabajo que toleran tráfico en frío o tienen regiones calientes cambiantes, a costa de la latencia en el primer acceso.
2. Precalentar solo páginas calientes: ejecute consultas representativas o toque páginas de un manifiesto del conjunto caliente antes del readiness. Transfiere un costo acotado a una fase más temprana y suele ser más controlado que escanear 20 GiB, pero la definición del conjunto caliente debe mantenerse.
3. Proporcionar sugerencias de acceso con madvise: MADV_WILLNEED indica que el rango se necesitará pronto, permitiendo read-ahead. Los patrones secuenciales y aleatorios también cuentan con sugerencias distintas. Son sugerencias de rendimiento, no garantías de residencia.
4. Probar MAP_POPULATE: prefalla las tablas de páginas y provoca read-ahead para mapeos de archivos, reduciendo fallos bloqueantes posteriores. La contrapartida es un mmap y un arranque más lentos, presión concentrada de E/S y memoria, y el hecho de que un llenado incompleto no necesariamente hace fallar la llamada.
5. Mejorar la estructura del índice y el tamaño del working set: separe metadatos calientes de datos fríos, mejore la localidad y reduzca accesos aleatorios entre páginas. Esto es más duradero que un prefetching ciego.
6. Compuerta de tráfico (traffic gating): exponga la disponibilidad completa tras alcanzar una cobertura definida del conjunto caliente o un objetivo de tasa de fallos, con un tiempo de espera para evitar que un nodo quede no disponible indefinidamente.

Las huge pages pueden reducir la presión sobre el TLB, pero no eliminan la E/S de archivos ni corrigen un working set mal seleccionado. Evalúelas únicamente después de que la evidencia señale a los fallos de TLB como un cuello de botella primario y la granularidad de memoria, fragmentación y entorno de despliegue sean aceptables.

Ejemplo de respuesta de alta calidad

«Primero confirmaría que la región de 20 GiB sea un mapeo de archivo de solo lectura y que mmap ocurra antes de fork. mmap crea una relación entre un rango de direcciones virtuales y el archivo; no lee el archivo completo en memoria física. Por lo tanto, el VmSize de cada worker aumenta aproximadamente 20 GiB de inmediato, mientras que el RSS crece solo cuando las consultas tocan las páginas.

Un acceso consulta primero el TLB. Un fallo de TLB solo indica que la caché de traducciones reciente carece de la entrada. Si la entrada de la tabla de páginas es válida, permitida y residente, basta con un recorrido de la tabla de páginas y la carga en el TLB; no hay fallo de página. Un fallo ocurre únicamente cuando el estado de la tabla de páginas no puede satisfacer el acceso, como una página de archivo no residente, una primera escritura copy-on-write tras fork o un permiso no válido.

En cuanto a los contadores de Linux, defino menor como aquel que no requiere E/S de disco y mayor como aquel que sí la requiere. Tras un arranque en frío, las páginas del índice usadas por las primeras peticiones pueden no estar en la page cache, por lo que leerlas provoca fallos mayores y mayor latencia de cola. Repetir las mismas consultas aprovecha la page cache, por lo que puede generar solo fallos menores o usar mapeos existentes, y la latencia se reduce. Los fallos mayores no se limitan al swap; los mapeos respaldados por archivos pueden generarlos incluso en una máquina sin swap.

Los workers pueden compartir páginas de archivo de solo lectura, pero el RSS de cada worker contabiliza las páginas compartidas que tiene mapeadas. Yo no sumaría los valores de RSS directamente. Inspeccionaría PSS, RssFile, RssAnon y VmPTE en /proc/<pid>/smaps_rollup, para luego alinearlos con lecturas de bloques, deltas de fallos menores y mayores, y el p99 de peticiones en la misma ventana de 30 segundos.

Para la verificación, ejecutaría el mismo conjunto de consultas dos veces. Si los fallos mayores, la E/S de lectura y el p99 son elevados en la primera ejecución y caen juntos en la segunda, eso respalda la carga por demanda como causa principal. A continuación, mediría el working set caliente real. Si solo 2 GiB del índice de 20 GiB están calientes, precalentaría esa región antes del readiness y usaría una sugerencia adecuada de madvise para acceso secuencial o aleatorio. Si el SLO permite mayor costo de arranque, realizaría una prueba A/B con MAP_POPULATE. No escanearía todo el archivo por defecto ni trataría las huge pages como una solución genérica para fallos de página. La decisión final compararía el tiempo de inicio, el p99 del primer minuto, la tasa de fallos mayores, el PSS y la estabilidad tras la liberación de memoria».

Esta respuesta conecta los conceptos, las observaciones y la decisión en una cadena verificable. Si el entrevistador cambia el tipo de mapeo, el working set o el SLO de disponibilidad, el mismo marco generará una decisión diferente pero defendible.

Errores comunes

• Tratar VIRT como RAM ya consumida → un mapeo de archivo puede reservar un rango de direcciones sin hacer que cada página sea residente → inspeccione VmSize, RSS, PSS y el tipo de mapeo en conjunto.
• Equiparar un fallo de TLB con un fallo de página → una entrada válida y residente en la tabla de páginas solo necesita traducción → describa la búsqueda en TLB, el recorrido de la tabla de páginas y la condición de fallo por separado.
• Afirmar que todo fallo de página lee de disco → los aciertos en page cache, las páginas anónimas en cero y copy-on-write pueden producir fallos menores → utilice la distinción de E/S entre fallos menores y mayores en Linux.
• Afirmar que los fallos mayores solo provienen de swap → una página respaldada por archivo no almacenada en caché también requiere E/S de almacenamiento → identifique si la página con fallo es anónima o respaldada por archivo.
• Sumar el RSS de los 8 workers → las páginas de archivo compartidas se cuentan repetidamente → use PSS para prorratear las páginas compartidas y compare RssFile con RssAnon.
• Leer totales acumulados históricos de fallos → no demuestran una relación con una ventana particular de peticiones lentas → compare deltas de fallos, E/S y latencia en el mismo intervalo.
• Escanear los 20 GiB completos durante el arranque → esto puede desperdiciar E/S, retrasar el readiness y expulsar páginas más útiles → mida el conjunto caliente y precaliente solo lo que requiera el SLO.
• Asumir que MADV_WILLNEED u MAP_POPULATE eliminan futuros fallos → el primero es una sugerencia, el segundo puede completarse parcialmente y las páginas pueden liberarse más tarde → pruebe el comportamiento en arranque en frío y bajo presión de memoria.
• Habilitar huge pages de inmediato → modifican principalmente la cobertura de traducción y la granularidad de asignación, no la E/S de archivos ni la calidad del working set → primero demuestre que los fallos de TLB son predominantes.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: La máquina no tiene swap. ¿Por qué siguen ocurriendo fallos de página mayores?

Mayor significa que el manejo del fallo requirió E/S de disco; el origen no tiene que ser swap. El índice en este escenario está respaldado por archivo. Al primer acceso a una página de archivo que no está en la page cache, el kernel debe leerla desde el sistema de archivos, por lo que el acceso puede generar un fallo mayor. Inspeccione RssFile, la ruta mapeada y las lecturas de bloques en lugar de revisar únicamente VmSwap.

Pregunta de seguimiento 2: Otro worker ya leyó la misma página de archivo. ¿Qué sucede en el primer acceso de este worker?

La página puede encontrarse ya en la page cache del sistema mientras este worker carece de un mapeo en su tabla de páginas para ella. Establecer ese mapeo generalmente no requiere E/S de disco y puede aparecer como un fallo menor. Un acceso posterior puede experimentar aún un fallo de TLB, pero si la entrada de la tabla de páginas es válida, no es un fallo de página.

Pregunta de seguimiento 3: ¿Por qué escribir una cantidad pequeña tras fork puede aumentar el PSS?

Las páginas privadas pueden compartirse inicialmente mediante copy-on-write. En la primera escritura, el kernel crea una copia privada para el worker que escribe y actualiza su tabla de páginas. Una página compartida pasa a ser atribuible a un solo proceso, por lo que el PSS aumenta. El fallo normalmente no requiere E/S de disco, pero la asignación y el copiado siguen consumiendo tiempo. Un índice de solo lectura debe evitar escrituras accidentales en un mapeo privado.

Pregunta de seguimiento 4: ¿Qué ocurre si el acceso es aleatorio pero el servicio utiliza MADV_SEQUENTIAL?

Una sugerencia inadecuada puede desencadenar lecturas anticipadas inútiles, cargando páginas que no se utilizarán e incrementando la E/S. Para búsquedas puntuales aleatorias, pruebe MADV_RANDOM o la política predeterminada; si se conoce el conjunto caliente, es preferible un prefetching dirigido. Evalúe cada sugerencia mediante fallos, E/S, PSS y latencia en lugar de por su nombre.

Pregunta de seguimiento 5: ¿Cuándo es adecuado utilizar MAP_POPULATE?

Vale la pena realizar un experimento cuando el arranque puede invertir más tiempo y E/S, la latencia en línea del primer acceso deba ser estable y el rango de mapeo que se utilizará próximamente sea razonablemente predecible. Puede resultar ineficiente cuando el mapeo es mucho más grande que el conjunto caliente, los nodos escalan con frecuencia o la presión de memoria liberará las páginas pronto. Además, una falla en la carga no causa necesariamente el fallo de mmap, por lo que se debe medir la residencia real y los fallos posteriores.

Pregunta de seguimiento 6: ¿Cómo distinguiría la rotación por fallos de página de una fuga de memoria real?

Una fuga suele mostrar un crecimiento continuo de la memoria anónima privada o de objetos no liberables, incluso bajo tráfico estable. El crecimiento en un working set respaldado por archivo se manifiesta más en RssFile y en la page cache, y puede disminuir tras una liberación de memoria (reclaim). Compare RssAnon, RssFile, PSS, VmSwap y perfiles de heap u objetos, luego repita bajo tráfico estable y presión de memoria controlada. El crecimiento de RSS por sí solo no permite distinguir entre ambos casos.