¿Linux realiza intercambios oportunistas o es un mito?

proc:meminfo:calcule la memoria disponible de forma más conservadora

El MemAvailable artículo en /proc/meminfo es dar a los usuarios una pista de cuánta memoria se puede asignar sin causar un intercambio, por lo que excluye las marcas de agua bajas de las zonas como no disponibles para el espacio del usuario.

Sin embargo, para una asignación de espacio de usuario, kswapd en realidad reclamará hasta que las páginas gratuitas alcancen una combinación de la marca de agua alta y la protección de memoria baja del asignador de páginas que también mantiene una cierta cantidad de memoria DMA y DMA32 del espacio del usuario.

Resta la cantidad total que sabemos que no está disponible para el espacio de usuario de la cantidad de páginas libres al calcular MemAvailable.

Código Linux

A veces se afirma que cambiar swappiness a 0 deshabilitará efectivamente el "intercambio oportunista". Esto proporciona una interesante vía de investigación. Si hay algo llamado "intercambio oportunista", y se puede ajustar mediante swappiness, entonces podríamos perseguirlo encontrando todas las cadenas de llamadas que dicen vm_swappiness . Tenga en cuenta que podemos reducir nuestro espacio de búsqueda asumiendo CONFIG_MEMCG no está configurado (es decir, los "cgroups de memoria" están deshabilitados). La cadena de llamadas va:

• vm_swappiness
• mem_cgroup_swappiness
• get_scan_count
• shrink_node_memcg
• shrink_nodo

shrink_node_memcg se comenta "Esta es una página básica por nodo más libre. Utilizada tanto por kswapd como por reclamo directo". Es decir. esta función aumenta el número de gratis paginas No está tratando de duplicar páginas para intercambiar para que puedan liberarse mucho más tarde. Pero incluso si descontamos eso:

La cadena anterior se llama desde tres funciones diferentes, que se muestran a continuación. Como era de esperar, podemos dividir los sitios de llamada en reclamo directo vs. kswapd. No tendría sentido realizar un "intercambio oportunista" en la recuperación directa.

1. /*
    * This is the direct reclaim path, for page-allocating processes.  We only
    * try to reclaim pages from zones which will satisfy the caller's allocation
    * request.
    *
    * If a zone is deemed to be full of pinned pages then just give it a light
    * scan then give up on it.
    */
   static void shrink_zones
   

2.  * kswapd shrinks a node of pages that are at or below the highest usable
    * zone that is currently unbalanced.
    *
    * Returns true if kswapd scanned at least the requested number of pages to
    * reclaim or if the lack of progress was due to pages under writeback.
    * This is used to determine if the scanning priority needs to be raised.
    */
   static bool kswapd_shrink_node
   

3.  * For kswapd, balance_pgdat() will reclaim pages across a node from zones
    * that are eligible for use by the caller until at least one zone is
    * balanced.
    *
    * Returns the order kswapd finished reclaiming at.
    *
    * kswapd scans the zones in the highmem->normal->dma direction.  It skips
    * zones which have free_pages > high_wmark_pages(zone), but once a zone is
    * found to have free_pages <= high_wmark_pages(zone), any page in that zone
    * or lower is eligible for reclaim until at least one usable zone is
    * balanced.
    */
   static int balance_pgdat
   

Entonces, presumiblemente, la afirmación es que kswapd se activa de alguna manera, incluso cuando todas las asignaciones de memoria se satisfacen inmediatamente desde la memoria libre. Revisé los usos de wake_up_interruptible(&pgdat->kswapd_wait) , y no veo ningún despertar como este.

No, no existe el intercambio oportunista en Linux. Pasé un tiempo analizando el problema y todas las fuentes (libros de texto, correos electrónicos en las listas de correo de los desarrolladores del kernel, código fuente de Linux y comentarios de confirmación, y algunos intercambios de Twitter con Mel Gorman) me dicen lo mismo:Linux solo reclama memoria en respuesta a alguna forma de presión de la memoria (con la obvia excepción de la hibernación).

Todos los conceptos erróneos populares sobre el tema probablemente se derivan del simple hecho de que Linux no puede darse el lujo de esperar hasta el último byte de memoria libre antes de comenzar el intercambio. Necesita algún tipo de colchón para protegerlo de formas extremas de agotamiento de la memoria, y hay algunos ajustes que pueden afectar el tamaño de ese colchón (por ejemplo, vm.min_free_kbytes ). Pero no es lo mismo que "cambiar porque no hay nada mejor que hacer".

Desafortunadamente, el algoritmo de recuperación de marcos de página se ha vuelto mucho más complejo con respecto a 2.6 (cuando se describió en detalle en el libro de Mel Gorman), pero la idea básica es más o menos la misma:la recuperación de página se desencadena por asignaciones fallidas, que luego despierta kswapd o intente liberar páginas sincrónicamente (según la presión de la memoria, los indicadores de asignación y otros factores).

La razón más obvia por la que las asignaciones de páginas pueden comenzar a fallar con suficiente memoria libre es que pueden estar solicitando memoria contigua cuando en realidad la memoria puede estar demasiado fragmentada para satisfacer la solicitud. Históricamente, los desarrolladores del kernel de Linux hicieron todo lo posible para evitar la necesidad de asignaciones contiguas. Sin embargo, algunos controladores de dispositivos todavía requieren eso, ya sea porque no pueden hacer E/S de memoria de varias páginas (DMA de dispersión y recopilación), o porque los desarrolladores de controladores pueden codificar de manera descuidada. La llegada de Transparent Huge Pages (THP) proporcionó otra razón para asignar memoria en fragmentos físicamente contiguos.

Se supone que la compactación de zonas, que se introdujo aproximadamente al mismo tiempo, ayuda con el problema de fragmentación de la memoria, pero no siempre produce el efecto esperado.

Hay varios vmscan puntos de rastreo que pueden ayudar a comprender qué está pasando exactamente en su caso específico:siempre es más fácil encontrar lo que necesita en el código del kernel de Linux cuando tiene pilas de llamadas específicas, en lugar de simplemente escanear todo lo que parece remotamente relevante.