Romano Gushchin (um engenheiro de software do Facebook) registrou um conjunto de correções para o aplicativo de alocação de memória do driver slab (um controlador de memória) na lista de discussão de desenvolvimento do kernel Linux.
O novo driver se destaca por mover a contabilização de slabs do nível das páginas de memória para o nível dos objetos do kernel, possibilitando o compartilhamento de páginas de slab entre diferentes grupos de cache (c-groups), em vez de alocar caches de slab separados para cada grupo de cache.
Roman encontrou o que ele chama de "falha muito séria" no controlador de memória slab existente que leva à baixa utilização atualmente com cgroups.
“A verdadeira razão pela qual o design existente leva a uma baixa utilização de placas é simples: as páginas de placas são usadas exclusivamente por um pool de memória.
Se houver apenas algumas alocações de um certo tamanho feitas por um cgroup, ou se houver alguns objetos ativos deixados após o cgroup ser removido, ou o cgroup contém um único aplicativo threaded que mal está alocando quaisquer objetos de kernel, mas sempre uma nova CPU: em todos esses casos, a utilização da placa resultante é muito baixa.
Se a contabilidade do kmem estiver desabilitada, o kernel pode usar o espaço livre nas páginas slab para outras alocações. «
O controlador de memória Slab proposto por Romano Gushchin no ano passado mostrou-se bastante promissor, pois permite maior eficiência no uso de slabs, reduz o tamanho da memória utilizada para slabs em 30 a 45% e diminui significativamente o consumo total de memória do núcleo.
Além disso, as correções implementadas indicaram que o Facebook já está usando o código em produção em seus servidores e economizando cerca de 650 a 700 MB em servidores web front-end , cache de banco de dados e servidores DNS, entre outros benefícios.
A redução do número de blocos não móveis também tem um efeito positivo na fragmentação da memória. O novo controlador de memória simplifica significativamente o código para contabilização dos blocos e elimina a necessidade de algoritmos complexos para a criação e exclusão dinâmica de caches de blocos para cada grupo de memória (c-group).
Todos os cgroups para memória na nova implementação usam um conjunto comum de caches slab, e a vida útil dos caches slab não está mais ligada à vida útil das restrições de memória definidas por meio do cgroup.
A contabilização de recursos mais precisa implementada no novo controlador de placa deveria, teoricamente, carregar mais a CPU, mas na prática as diferenças acabaram sendo insignificantes.
Em particular, o novo controlador slab tem sido usado há vários meses em servidores ativos do Facebook, lidando com diferentes tipos de cargas, e até agora nenhuma regressão significativa foi detectada.
O patch contém algumas partes semi-independentes, que também podem ser usadas fora do controlador de memória da placa:
- A API de carregamento de subpágina, que pode ser usada no futuro para contar outros objetos que não são do tamanho de uma página, por exemplo, alocações de percpu
- A API mem_cgroup_ptr, em que os ponteiros são contados para um memcg, pode ser reutilizada para uma nova geração eficiente de outros objetos, por exemplo, pagecache.
Ao mesmo tempo, observa-se uma redução significativa no consumo de memória : em alguns hosts foi possível economizar até 1 GB de memória, mas esse indicador depende muito da natureza da carga, do tamanho total da RAM, da quantidade de CPU e das características de utilização da memória.
Em vez de criar um conjunto separado de kmem_caches para cada cgroup de memória, dois conjuntos globais são usados: o conjunto raiz para não contados e as atribuições de cgroup do grupo raiz e o segundo conjunto para todas as outras atribuições. Isso permite simplificar o gerenciamento do tempo de vida de kmem_caches individuais.
Por fim, se você estiver interessado em saber mais sobre o novo conjunto de 19 patches, pode encontrá-lo na lista de discussão do kernel.