LinuxParty

NUESTRO SITIO necesita la publicidad para costear hosting y el dominio. Por favor considera deshabilitar tu AdBlock en nuestro sitio. También puedes hacernos una donación entrando en linuxparty.es, en la columna de la derecha.
Inicio desactivadoInicio desactivadoInicio desactivadoInicio desactivadoInicio desactivado
 

Asginación de losas.

Roman Gushchin, miembro del equipo de ingeniería de kernel de Linux de Facebook, ha propuesto un nuevo controlador de memoria losa para el kernel de Linux. Este nuevo controlador de memoria de losa promete proporcionar una utilización de memoria mejorada entre múltiples grupos de memoria, a través del intercambio de páginas de losa.

¿Qué es una Slab Page (pagina de losa)?

La asignación de losas es una forma de gestión de memoria, dentro del núcleo de Linux, utilizada con la intención de hacer eficiente la asignación de memoria de objetos. Este tipo de gestión de memoria reduce la fragmentación causada por asignaciones y desasignaciones. La asignación de losas retiene la memoria asignada para su reutilización en asignaciones posteriores de objetos similares y proporciona un menor costo general de inicialización de objetos.

La asignación de losas implica un caché para un cierto tipo / tamaño de objeto. Ese caché tiene una cantidad de "losas" de memoria preasignadas, agrupadas en tamaños fijos que son adecuados para objetos específicos. Dentro del núcleo, hay un asignador de losas que gestiona los fragmentos de tal manera que cuando (el núcleo) recibe una solicitud para asignar memoria para un objeto, puede satisfacer esa solicitud con un fragmento libre de una losa existente.

El nuevo controlador de losa

Gushchin descubrió lo que él considera una "falla grave" en el controlador de memoria de losa actual. Según Gushchin, “la verdadera razón por la cual el diseño existente conduce a una baja utilización de losa es simple: las páginas de losa 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 (por ejemplo, dentries) después de que se elimina el cgroup , o el cgroup contiene una aplicación de un solo subproceso que apenas asigna ningún objeto del núcleo, pero lo hace cada vez en una nueva CPU: en todos estos casos, la utilización de la losa resultante es muy baja. Si la contabilidad kmem está desactivada, el kernel 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 tuvo que activarse para cada grupo de memoria. Ahora, sin embargo, el controlador kmem está activado de forma predeterminada para cgroup v1 y v2. Y dado que los sistemas modernos basados ​​en systemd tienden a crear una gran cantidad de grupos c, la utilización de losas se vuelve menos eficiente.

Al compartir páginas en losa entre múltiples grupos de memoria (y emplear un sistema donde la contabilidad se realiza por objeto, en lugar de por página), esta nueva implementación del controlador de memoria en losa apunta a alcanzar un nivel mucho más eficiente de utilización.

Según Gushchin, el nuevo parche contiene dos piezas semiindependientes:

  • API de carga de subpágina , que se puede usar en el futuro para contabilizar otros objetos que no sean del tamaño de una página, por ejemplo, asignaciones de percpu.
  • mem_cgroup_ptr API (punteros contados a un memcg, se pueden reutilizar para la reparación eficiente de otros objetos, por ejemplo, pagecache.

El nuevo controlador de memoria losa de Gushchin ha sido probado en numerosas cargas de trabajo. Los resultados de las pruebas muestran ahorros significativos en el uso de la memoria, que incluyen:

  • Interfaz web, 650-700 Mb, ~ 42% de la memoria de losa.
  • Caché de la base de datos, 750-800 Mb, ~ 35% de la memoria de losa
  • Servidor DNS, 700 Mb, ~ 36% de la memoria de losa

Con este nuevo controlador, es posible obtener entre 35 y 42% de mejor uso de memoria en Linux. Gushchin señaló en este hilo de lkml.org que nada en sus pruebas era específico de Facebook. Indicó que había probado el parche en una instalación de Fedora 30 y encontró que los números eran más o menos los mismos.

El parche de Gushchin está actualmente bajo una bandera de "solicitud de comentarios". Si se acepta, podría llegar al núcleo de la línea principal ya en 2020.

Vía: thenewstack.io

Pin It

Escribir un comentario


Código de seguridad
Refescar



Redes:



 

Suscribete / Newsletter

Suscribete a nuestras Newsletter y periódicamente recibirás un resumen de las noticias publicadas.

Donar a LinuxParty

Probablemente te niegues, pero.. ¿Podrías ayudarnos con una donación?


Tutorial de Linux

Filtro por Categorías