Por que o Debian Linux permite até 128TiB de espaço de endereço virtual por processo, mas apenas 64TiB de memória física?


23

Acabei de ler aqui :

  • até 128TiB de espaço de endereço virtual por processo (em vez de 2GiB)
  • Suporte à memória física de 64TiB em vez de 4GiB (ou 64GiB com a extensão PAE)

Por que é que? Quero dizer, o suporte à memória física está sendo limitado pelo kernel ou pelo hardware atual?

Por que você precisaria o dobro do espaço de memória virtual do que a memória física que você pode realmente endereçar?


Você também pode adicionar swap.
Thorbjørn Ravn Andersen

2
isso é um monte de RAM ...
dalearn

4
@dalearn - você sabe, quando eu aprendi que você poderia começar de expansão de memória de comutação de banco para micros de 8 bits que lhes permitem ter até 4096KB, eu disse exatamente a mesma coisa ...
Jules

Respostas:


35

Esses limites não vêm do Debian ou do Linux, eles vêm do hardware. Arquiteturas diferentes (processador e barramento de memória) têm limitações diferentes.

Nos atuais processadores x86-64 para PC, a MMU permite 48 bits de espaço de endereço virtual . Isso significa que o espaço de endereço está limitado a 256 TB. Com um bit para distinguir os endereços do kernel dos endereços da terra do usuário, isso deixa 128 TB para o espaço de endereço do processo.

Nos atuais processadores x86-64, os endereços físicos podem usar até 48 bits , o que significa que você pode ter até 256 TB. O limite aumentou progressivamente desde a introdução da arquitetura amd64 (de 40 bits, se bem me lembro). Cada bit de espaço de endereço custa alguma lógica de fiação e decodificação (o que torna o processador mais caro, mais lento e mais quente), para que os fabricantes de hardware tenham um incentivo para manter o tamanho baixo.

O Linux permite apenas endereços físicos de até 2 ^ 46 (portanto, você só pode ter até 64 TB) porque permite que a memória física seja totalmente mapeada no espaço do kernel. Lembre-se de que existem 48 bits de espaço de endereço; um bit para o kernel / usuário deixa 47 bits para o espaço de endereço do kernel. Metade disso, no máximo, endereça a memória física diretamente, e a outra metade permite que o kernel mapeie o que for necessário. (O Linux pode lidar com a memória física que não pode ser mapeada na íntegra ao mesmo tempo, mas isso introduz complexidade adicional, por isso é feito apenas em plataformas onde é necessário, como x86-32 com PAE e armv7 com LPAE.)

É útil que a memória virtual seja maior que a memória física por vários motivos:

  • Ele permite que o kernel mapeie toda a memória física e tenha espaço para mappins virtuais.
  • Além dos mapeamentos da memória física, existem mapeamentos de troca, de arquivos e de drivers de dispositivo.
  • É útil ter memória não mapeada em alguns locais: páginas de proteção para capturar estouros de buffer , grandes zonas não mapeadas devido ao ASLR , etc.

9
A limitação de 46 bits na memória física está relacionada ao mapa de memória do Linux : inclui um mapeamento completo da memória física no espaço do kernel, o que significa que a memória física pode corresponder apenas a um quarto do espaço de endereço disponível.
Stephen Kitt

Alguém poderia elaborar o comentário do @StephenKitt? Estou muito interessado em entender isso, mas mesmo depois de ler a referência ele citou não obtê-lo;)
GSI-franca

@ gsi-frank É conveniente que o kernel tenha toda a memória física mapeada permanentemente. Portanto, em um espaço de endereço de 2 ^ 48, 2 ^ 47 vai para endereços de usuário, 2 ^ 46 para endereços de kernel e 2 ^ 46 é para endereçamento de memória física.
Gilles 'SO- stop be evil'

@ gsi-frank Se você conseguir uma cópia do livro clássico " Desenvolvendo seu próprio sistema operacional de 32 bits ", isso será aprofundado em relação ao motivo pelo qual o autor tomou uma decisão semelhante para seu próprio sistema operacional (nesse caso, dividindo o espaço de endereço virtual 4GiB do 80386 em um segmento de kernel 2GiB que contém um mapeamento de RAM física de 1GiB e um segmento de usuário 2GiB). Qualquer pessoa interessada em componentes internos do sistema operacional provavelmente deve lê-lo - ele fornece um design completo, simples o suficiente para entender, mas avançado o suficiente para ser um kernel útil do sistema operacional.
Jules

Desde a versão 4.13 do kernel, x86-64 (e algumas outras arquiteturas) podem ser construídas com tabelas de paginação de cinco níveis , que aumentam o espaço de endereço em x86-64 para 52 bits para RAM física e 57 bits para virtual (4 PiB / 128 PiB). Observe que o mapa de memória no espaço do kernel apresenta problemas de segurança, o que pode mudar em um futuro próximo.
Stephen Kitt

9

Não sei por que, mas posso pensar em sete razões pelas quais seria útil suportar o dobro do espaço de endereço que a memória física.

  1. A primeira é para que você possa executar aplicativos que precisam de memória extra - mesmo que isso signifique trocar para o disco.
  2. Layouts de memória mais limpos para particionar o uso da memória. Por exemplo, um sistema operacional pode usar endereços com números mais altos e deixar endereços com números mais baixos para os aplicativos tornarem a separação mais limpa.
  3. A randomização do layout do espaço de endereço é um pouco mais eficaz.
  4. Marcar páginas como executáveis ​​pode significar sobras de memória.
  5. E / S mapeada na memória.
  6. A alocação de memória é mais fácil: é possível alocar partes maiores de cada vez.
  7. Fragmentação de memória reduzida

1
Obrigado! 1) é tão evidente e básico que me sinto constrangida pela pergunta;)
GSI-franca

2
(3) também é realmente importante. Você realmente quer um espaço de endereçamento virtual com ordens de magnitude maiores que a quantidade de memória que você estará alocando, para que suposições aleatórias quase certamente resultem em interceptações.
R ..

6

Essas são limitações de hardware. O hardware x86_64 / amd64 atual permite endereços virtuais de 48 bits e vários tamanhos (depende da implementação - por exemplo, minha estação de trabalho aqui suporta apenas 36 bits) endereços físicos. O kernel do Linux divide o espaço de endereço virtual pela metade (usando metade para o kernel e metade para o espaço do usuário - exatamente como no x86).

Então você obtém:

2⁴⁸ bytes ÷ 2 = 2⁴⁷ bytes = 128 TiB

O tamanho do endereço físico geralmente é menor porque é realmente físico. Ele ocupa pinos / pads, transistores, conexões etc. na / na CPU e linhas de rastreamento na placa. Provavelmente também o mesmo nos chipsets. Não faz sentido suportar uma quantidade de RAM que é inconcebível durante a vida útil do design do núcleo ou soquete do processador - todas essas coisas custam dinheiro. (Mesmo com 32 slots DIMM e DIMMs de 64GiB em cada um, você ainda está apenas com 2TiB. Mesmo que a capacidade DIMM dobre anualmente, estamos a 5 anos do 64TiB.

Como Peter Cordes aponta, as pessoas agora estão conectando armazenamento não volátil, como o 3D XPoint, ao barramento de memória, o que torna possível a falta de espaço de endereço. Os processadores mais recentes estenderam o espaço de endereço físico para 48 bits; é possível que o wiki Debian não tenha sido atualizado.


O armazenamento não volátil conectado diretamente ao barramento de memória (por exemplo, 3D XPoint) está se tornando uma coisa e isso pode aumentar muito a demanda por espaço de endereço físico nos próximos anos (já que é mais denso que a DRAM e é útil ter cargas de barco) em mais casos do que é útil ter cargas de barco de RAM). Consulte zdnet.com/article/the-non-volatile-memory-revolution para obter um artigo não muito técnico (ou o google para obter coisas melhores). O Intel Skylake o suporta com instruções clflushe clflushopt.
Peter Cordes

1
Você já pode comprar sistemas com até 12TiB de RAM em 96 slots ( por exemplo, o sistema HPC de quatro soquetes da Tyan ); portanto, 64TiB pode estar a menos de cinco anos. E algumas pessoas não comprá-los e prepará-los com tanta RAM ...
Stephen Kitt

@StephenKitt hmm, é OK porque a capacidade DIMM leva mais perto de 3 anos para dobrar 😁
derobert

Acontece que você pode realmente comprar sistemas com 64 TiB de RAM agora.
Stephen Kitt
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.