Romano Gushchin (un ingeniero de software de Facebook) registró en lista de desarrollo del núcleo de Linux, un conjunto de parches a la aplicación de asignación de memoria del controlador slab (un controlador de memoria).

El nuevo controlador es notable por mover la contabilidad de slab desde el nivel de las páginas de memoria al nivel de los objetos del núcleo, lo que hace posible compartir páginas de slab en diferentes grupos c, en lugar de asignar cachés de slab separadas para cada grupo c.

Roman encontró lo que él llama un “defecto muy serio” en el controlador de memoria de slab existente que conduce a una baja utilización en estos días con cgroups.

“La verdadera razón por la cual el diseño existente conduce a una baja utilización de slab es simple: las páginas de slab son utilizadas exclusivamente por un 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 se elimina el cgroup, o el cgroup contiene una aplicación de un solo subproceso que apenas está asignando ningún objeto del núcleo, pero cada vez en una nueva CPU: en todos estos casos, la utilización de la slab resultante es muy baja.

Si la contabilidad de kmem está desactivada, el núcleo puede usar el espacio libre en las páginas de slab para otras asignaciones. “

El controlador de memoria Slab propuesto por Romano Gushchin en el año pasado fue bastante prometedor pues permite aumentar la eficiencia del uso de la slab, reducir el tamaño de la memoria utilizada para slab en un 30-45% y reducir significativamente el consumo total de memoria del núcleo.

Ademas, los parches implementados han señalado que Facebook ya está usando el código en producción en sus servidores y estaba ahorrando ~ 650-700MB + para servidores front-end web, almacenamiento en caché de bases de datos y servidores DNS, entre otros premios.

Al reducir el número de slab no móviles, también se observa un efecto positivo en el campo de la reducción de la fragmentación de la memoria. El nuevo controlador de memoria simplifica significativamente el código para contabilizar slab y no requiere algoritmos complicados para la creación dinámica y la eliminación de cachés de slab para cada grupo c.

Todos los cgroups para memoria en la nueva implementación usan un conjunto común de cachés de slab, y la vida útil de los cachés de slab ya no está vinculada a la vida útil de las restricciones de memoria establecidas a través de cgroup.

La contabilidad de recursos más precisa implementada en el nuevo controlador de slab teóricamente debería cargar más la CPU, pero en la práctica las diferencias resultaron ser insignificantes.

En particular, el nuevo controlador de slab se ha utilizado durante varios meses en servidores de Facebook en funcionamiento que manejan diferentes tipos de cargas, y hasta ahora no se han detectado regresiones significativas.

El parche contiene un par de partes semi-independientes, que también pueden encontrar su uso fuera del controlador de memoria de slab:

• La API de carga de subpágina, que se puede usar en el futuro para contabilizar otros objetos que no son del tamaño de una página, por ejemplo, asignaciones percpu
• La API mem_cgroup_ptr, en donde los punteros contados a un memcg, se pueden reutilizar para el reparenting eficiente de otros objetos, por ejemplo, pagecache.

Al mismo tiempo, hay una disminución significativa en el consumo de memoria: en algunos hosts era posible ahorrar hasta 1 GB de memoria, pero este indicador depende en gran medida de la naturaleza de la carga, el tamaño total de RAM, la cantidad de CPU y las características de trabajar con memoria.

En lugar de crear un conjunto individual de kmem_caches para cada cgroup de memoria, se utilizan dos conjuntos globales: el conjunto raíz para no contabilizado y el grupo raíz cgroup asignaciones y el segundo conjunto para todas las demás asignaciones. Esto permite simplificar la gestión de por vida de kmem_caches individuales.

Finalmente, si estas interesado en conocer el nuevo conjunto de 19 parches se puede encontrar en la lista de correo del kernel.