Sobre uma página enorme e tradução Lookaside Buffer

Question

eles me confundem.

página enorme: a maneira de gerenciar a memória física do kernel do sistema operacional é dividir uma página enorme pelo kernel para reduzir o número do índice na tabela de páginas.

Eu obtenho de: link

Buffer de tradução Lookaside: Um Translation Lookaside Buffer (TLB) é um cache de CPU que o hardware de gerenciamento de memória usa para melhorar a velocidade de tradução de endereço virtual.

página enorme (nível do sistema operacional) Tradução Buffer Lookaside (cache da CPU)

link Como diz o documento, / proc / sys / vm / nr_hugepages indica o número atual de páginas enormes "persistentes" no enorme conjunto de páginas do kernel.

No meu servidor

echo 40 > /proc/sys/vm/nr_hugepages   
cat /proc/meminfo | grep -i hugepage   
AnonHugePages:   1675264 kB   
HugePages_Total:      40   
HugePages_Free:       40  
HugePages_Rsvd:        0   
HugePages_Surp:        0   
Hugepagesize:       2048 kB 

em seguida, são minhas perguntas.

1. Qual é a média sobre o AnonHugePages? porque é 1675264KB? Eu acho que existem 40 x 2048 KB de memória de página enorme. Não consigo entender.

2. Por que não consigo modificar o Hugepagesize? Em teoria, o kernel poderia modificar o tamanho. talvez apenas não a interface no kernel.

3. Como posso obter o tamanho do Buffer de Tradução Lookaside? Eu acho que o kernel do sistema sabe o tamanho, porque o kernel irá usá-lo.

Espero expressar com clareza.
:)

    

Answer 1

O AnonHugePages é usado pelo kernel para "páginas grandes transparentes". Eles são contabilizados separadamente do "HugePages_Total" listado em meminfo.

Originalmente, para usar páginas enormes, seu aplicativo precisava suportá-las diretamente. Java faz, o Oracle faz. Tenho certeza de que existem outros grandes usuários de memória que os usam. Eles também devem ser configurados manualmente. Como alternativa, seu aplicativo precisava usar o hugetlbfs, que é uma interface específica para o uso de páginas grandes. O hugetlbfs usa o conjunto de sistemas de "hugepages" regulares, como aplicativos que usam as páginas enormes diretamente.

Mais recentemente, há uma adição de páginas amplas transparentes. Teoricamente, isso oferece os benefícios de páginas maiores sem o custo de modificar seus aplicativos. Um thread do kernel chamado khugepaged varre a memória e mescla páginas padrão em páginas maiores. O Red Hat 6 adiciona páginas de entrada transparentes. Eu não sei o que outras distros têm, mas eu sei que este é um trabalho em andamento.

Na prática, isso às vezes causa problemas com a capacidade de resposta do sistema. Eu tive problemas com um sistema executando muitos aplicativos java com muita memória (que não foram configurados manualmente para usar as páginas maiores). O sistema tem 128 GB de RAM e executa o RHEL6. Depois de 90 dias, a memória ficaria fragmentada. Neste ponto, teríamos pausas no sistema de um minuto ou dois, presumivelmente, a memória estava bloqueada enquanto o khugepaged corria. Desativar as abraepages transparentes melhorou imediatamente. Ainda tivemos alguns problemas de desempenho, mas configurar o java para usar as páginas de abertura manuais corrigiu as coisas.

Esta apresentação tem uma boa e detalhada explicação sobre as páginas principais:

link

    

Answer 2

O tamanho do TLB depende da marca e modelo da CPU. O tamanho de páginas grandes é fixo (pela CPU) em 4 MiB ou 2 MiB quando o PAE está habilitado. O AnonHugePages conta lá, não posso fazer sentido, pois se realmente existem 40 páginas enormes, isso seria 80 MiB, que não está nem perto desse número.