Quais CPUs suportam páginas de 1 GB?

Algumas CPUs Intel suportam páginas de 1 GB. Isso é identificado olhando no CPUID 0x80000001, EDX bit 26 . O kernel do Linux expõe isso /proc/cpuinfocomo o pdpe1gbsinalizador .

Onde descobrimos quais CPUs suportam isso e quais não? Ou que linha de produtos suporta esse recurso? Não há nada nessas páginas do Intel ARK que indique suporte para esse recurso.

CPUs que fazer apoio páginas 1GB:

Xeon E5620 (Westmere)
Core i5-4250U ( Haswell, dispositivo móvel )

Outras CPUs que não suportam páginas de 1 GB:

Xeon E5506 (Nehalem)
Core i7-2720QM (Sandy Bridge, dispositivos móveis)
Core i5-2500K (Sandy Bridge)

cpu

— Jonathon Reinhart
fonte

Relacionado: Como usar as páginas Intel Westmere de 1 GB no Linux?

— Jonathon Reinhart

De acordo com esta página :

além de suas páginas padrão de 4 KB, os processadores x86-64 mais recentes, como os processadores AMD64 mais recentes da AMD e os processadores Westmere da Intel e posteriores, podem usar páginas de 1 GB no modo longo

Parece ser verdade, pois era um novo recurso das CPUs Westmere .

— Viacheslav Rodionov
fonte

Sim, eu definitivamente olhei para todas essas páginas da Wikipedia! No entanto, esta resposta não está correta. O Sandy Bridge é mais novo que Westmere, e agora tenho dois CPUs Sandy Bridge que não o suportam.

— Jonathon Reinhart

@ JonathonReinhart: a enorme desvantagem do Hugepages para uso geral, esp. 1G páginas, é que toda a enorme página está amarrando tanta RAM física. Se um processo aloca 1GiB normalmente, apenas as partes em que ele toca tocam a memória virtual. (a confirmação excessiva permite alocações que o kernel não tem espaço de troca suficiente para manipular). O Linux não pode paginar páginas enormes em disco, mesmo quando um processo é interrompido, portanto, uma alocação de páginas enormes efetivamente fixa / bloqueia muita memória física.

— Peter Cordes

Hugepages 2M faz sentido quando não será deixado meio vazio (por exemplo, quando você sabe com certeza que você está indo para escrever todos os 4k da 2M de qualquer maneira), mas a falta de paginação é um grande negócio. Projetar software de uso geral para funcionar terrivelmente mal em desktops com pouca memória não é uma boa idéia. Eu não acho que você possa mapear um arquivo no disco com páginas enormes de 2M, mas seria uma má idéia para executáveis, porque haverá algumas páginas de 4k em um bloco de 2M que não serão tocadas. Eles podem ser despejados do pagecache (assumindo que foram pré-buscados), liberando RAM.

— 112615 Peter Cordes

Com as CPUs atuais com TLBs de vários níveis, o tempo total gasto em falhas de TLB provavelmente não é tão ruim, é? Eu não tenho perfilado grandes coisas como o Firefox. Eu estaria interessado em ver um resumo legível de quanto tempo gasta em perdas de TLB, (especialmente percursos de página) e coisas como falhas de cache I de L1. Eu sei que eu poderia apenas apontar perfpara isso ... Mesmo se você quisesse usar páginas enormes da 2M para o Firefox, eu acho que muitos dos seus dados internos estão alocados em pedaços menores do que isso. Haveria sobrecarga para garantir que você minimizasse a fragmentação externa de alocações dentro de um enorme buffer de páginas.

— Peter Cordes

As perdas de TLB são caras em operações de acesso aleatório e com alta memória, como muitos aplicativos de banco de dados. Páginas enormes fazem uma diferença significativa - mas mesmo lá, elas estão falando de 2 MB, não de 1 GB. O sistema operacional é o usuário mais provável de páginas de 1 GB através do mapeamento direto de todo o espaço de endereço físico.

— GreenReaper