O MGLRU continua a parecer muito promissor para o desempenho do kernel Linux

 

Confira !!!

Uma das muitas séries de patches de kernel promissoras no momento para melhorar o desempenho do kernel do Linux é a estrutura LRU multigeração ( MGLRU ) desenvolvida pelos engenheiros do Google. Eles descobriram que o código de recuperação da página do kernel Linux atual é muito caro para os recursos da CPU e pode fazer escolhas ruins de despejo, enquanto o MGLRU visa produzir melhor desempenho . Esses resultados são bastante tentadores e o MGLRU está agora em sua nona revisão.

Enviados ontem foram os patches MGLRU v8 para continuar a arrumar esta estrutura LRU multi-geração para melhorar o comportamento de recuperação de página do kernel Linux.

Embora Linus Torvalds não se oponha ao MGLRU, ele levantou objeções novamente sobre a opção Kconfig "TIERS_PER_GEN" proposta como parte desta série de patches. Isso permite um número configurável de camadas por geração no MGLRU entre 2 e 4. Torvalds acredita que essa opção é muito confusa, especialmente porque o valor errado pode levar a um erro de compilação e um valor que a maioria dos usuários provavelmente não saberá como definir melhor.

O valor padrão é sensato e, portanto, seguindo a orientação de Torvalds, o MGLRU v9 foi girado para descartar essa opção confusa e desnecessária.

O MGLRU parece bom nos próprios testes do Google:

5. O Apache Cassandra alcançou 95% CIs [1,06, 4,10]%, [1,94, 5,43]% e [4,11, 7,50]% mais operações por segundo (OPS), respectivamente, para acesso exponencial (distribuição), acesso aleatório e Zipfian ( distribuição) acesso, quando o swap estava desligado; 95% CIs [0,50, 2,60]%, [6,51, 8,77]% e [3,29, 6,75]% mais OPS, respectivamente, para acesso exponencial, acesso aleatório e acesso Zipfian, quando a swap estava ativada.

6. O Apache Hadoop levou 95% CIs [5,31, 9,69]% e [2,02, 7,86]% menos tempo médio de parede para concluir doze tarefas paralelas do TeraSort, respectivamente, nas condições de média e alta simultaneidade, quando a troca estava ativada. Não houve mudanças estatisticamente significativas no tempo médio de parede para o resto da matriz de referência.

7. O PostgreSQL alcançou 95% CI [1,75, 6,42]% a mais de transações por minuto (TPM) na condição de alta simultaneidade, quando a troca estava desativada; 95% CIs [12,82, 18,69]% e [22,70, 46,86]% mais TPM, respectivamente, nas condições de média e alta simultaneidade, quando o swap estava ativado. Não houve mudanças estatisticamente significativas no TPM para o restante da matriz de benchmark.

8. O Redis alcançou 95% CIs [0,58, 5,94]%, [6,55, 14,58]% e [11,47, 19,36]% mais operações totais por segundo (OPS), respectivamente, para acesso sequencial, acesso aleatório e acesso gaussiano (distribuição) , quando THP=sempre; 95% ICs [1,27, 3,54]%, [10,11, 14,81]% e [8,75, 13,64]% mais OPS total, respectivamente, para acesso sequencial, acesso aleatório e acesso gaussiano, quando THP=never.

Também houve resultados independentes incluídos na série de patches:

Konstantin relatou: 

Eu tenho Archlinux com 8G RAM + zswap + swap. Durante o desenvolvimento, eu tenho muitos aplicativos abertos, como vários servidores LSP para diferentes idiomas, bate-papos, dois navegadores, etc. , reinicie os navegadores para liberar memória, etc, caso contrário, o sistema ficará muito lento e dificilmente poderá ser usado.

1,5 dia atrás eu migrei do kernel 5.11.15 para 5.12 + o patchset LRU, e comecei abrindo muitos aplicativos para criar pressão de memória e trabalhei por um dia como este. Até agora eu não tive uma única tempestade SWAP, e lembre-se que eu tenho 3.4G em SWAP. Eu nunca estava chegando ao ponto de 3G em SWAP antes sem uma única tempestade de SWAP.

Vaibhav da IBM relatou:

Em um Benchmark sintético do MongoDB, vendo uma média de ~19% de melhoria na taxa de transferência no POWER10 (Radix MMU + 64K Page Size) com patches MGLRU em cima do kernel v5.16 para MongoDB + YCSB em três distribuições de solicitação diferentes, a saber, Exponential, Uniform e Zipfan.

Shuang de U de Rochester relatou:

Com o MGLRU, o fio alcançou 95% CIs [38,95, 40,26]%, [4,12, 6,64]% e [9,26, 10,36]% maior taxa de transferência, respectivamente, para acesso aleatório, acesso Zipfian (distribuição) e acesso Gaussiano (distribuição), quando o número médio de jobs por CPU é 1; 95% CIs [42,32, 49,15]%, [9,44, 9,89]% e [20,99, 22,86]% maior throughput, respectivamente, para acesso aleatório, acesso Zipfian e acesso Gaussian, quando o número médio de jobs por CPU é 2.

Daniel da Michigan Tech relatou: 

Com o Memcached alocando ~100 GB de Optante endereçável por byte, a melhoria de desempenho em termos de taxa de transferência (medida como consultas por segundo) foi de cerca de 10% para uma série de cargas de trabalho.

O MGLRU parece bom e, com um pouco de sorte, espera-se que seja incorporado ao kernel Linux em breve.

Fonte

Até a próxima !!