El administrador de memoria es un subconjunto del sistema operativo que comparte la memoria entre el sistema operativo y las diversas aplicaciones. El término memoria se refiere principalmente a la memoria principal (RAM), pero su gestión requiere la contribución de la memoria auxiliar y la memoria caché.

El administrador de memoria es especialmente responsable de asignar eficientemente la memoria a los procesos, lo que implica que debe ser capaz de enumerar las ubicaciones libres de la memoria disponible, asignar la memoria necesaria para los nuevos procesos y recuperar la memoria de los procesos que terminan. El asignador de procesos dentro del kernel de Linux es el asignador SLAB.

SLAB se basa en un sistema de bloque y caché que optimiza las solicitudes de memoria. Este tipo de gestión de memoria reduce la fragmentación causada por las operaciones de asignación y reubicación.

La asignación de bloques implica la implementación de un caché para un determinado tipo / tamaño de objeto que tiene varios bloques de memoria preasignados cortados en piezas de tamaño fijo que son adecuadas para objetos específicos.

SLAB gestiona las piezas para que cuando se solicite al núcleo la asignación de memoria a un objeto, pueda satisfacer esa solicitud con una pieza libre de un bloque existente. SLAB retiene la memoria asignada para su reutilización, cuando las asignaciones posteriores de objetos similares, y por lo tanto reduce los costos generales relacionados con la inicialización del objeto.

Pretenden remplazar SLAB

Roman Gushchin, miembro del equipo de ingeniería de kernel de Linux en Facebook, descubrió lo que él ve como un “defecto grave” en el controlador/administrador de memoria actual. Y recientemente propuso un nuevo controlador de memoria de bloque que promete mejorar drásticamente la utilización de la memoria entre múltiples “cgroups” (o grupos de control) de memoria.

Ante esto es importante tener en cuenta que cgroups se refiere a una característica del kernel de Linux que permite limitar, contar y aislar el uso de los recursos de un sistema (procesador, memoria, uso de disco, etc.) y el término “página de losa” podría asimilarse a proceso de asignación de memoria por SLAB.

Según Gushchin:

“la verdadera razón por la cual el diseño existente conduce a un bajo uso de SLAB es simple: las páginas de losa se usan exclusivamente por un solo grupo de memoria.

Si solo hay unas pocas asignaciones de cierto tamaño hechas por un cgroup o si quedan algunos objetos activos después de que el cgroup ha sido eliminado o si el cgroup contiene una aplicación de subproceso único que no asigna prácticamente ninguno kernel, pero lo hace cada vez en una nueva CPU: en todos estos casos, el uso resultante de SLAB es muy bajo.

Si el cálculo de kmem está deshabilitado, el núcleo puede usar el espacio libre en las páginas de losas para otras asignaciones “.

Gushchin argumenta que esto no fue un problema cuando se introdujo el controlador kmem como una función opcional que tenía que habilitarse para cada grupo de memoria.

Ahora, sin embargo, el controlador kmem está habilitado de forma predeterminada para cgroup v1 y v2. Y como los sistemas modernos tienden a crear una gran cantidad de grupos c, el uso de SLAB es menos efectivo.

Según él, al compartir las páginas de slab entre varios grupos de memoria y al usar un sistema reelaborado donde la contabilidad se realiza por objeto en lugar de por página, uno tendría en el kernel de Linux un controlador de memoria optimizado que ofrece un nivel de uso Mucho más eficiente.

El parche propuesto por Gushchin contiene dos elementos semi-independientes: una API de carga de subpágina que se puede utilizar en el futuro con fines contables y una API mem_cgroup_ptr.

Las pruebas realizadas con el nuevo controlador de memoria de Gushchin han demostrado que es posible obtener entre un 35% y un 42% más de memoria en Linux en la Web front-end, la caché de la base de datos y el servidor DNS y en muchas otras cargas de trabajo.

La propuesta de Gushchin se encuentra actualmente bajo la bandera de “solicitud de comentarios”. Si se acepta, podría integrarse en la versión del kernel de Linux para 2020.

Fuente: https://lkml.org/