Por que os processos de 32 bits possuem um limite de RAM de 2 GB?

Question

Estou curioso para saber por que há um limite de 2 GB para um processo de 32 bits em um sistema operacional de 32 bits. De acordo com a postagem do blog Chat Questão: Limites de memória para processos de 32 e 64 bits , o limite pode ser estendido para 3 GB, mas a questão permanece.

Eu vejo que o limite físico é de 4 GB, então são 2 ou 3 GB apenas codificados no Windows? Por que não 4 GB como um processo de 32 bits pode ter em um sistema operacional de 64 bits?

NOTA: Esta questão foi marcada como duplicada, mas a questão referenciada refere-se ao limite de 4 GB do espaço de endereçamento de 32 bits. Isso é NÃO o que estou perguntando. Estou perguntando especificamente por que o Windows limita os processos a 2 GB - mesmo em uma plataforma de 32 bits. A resposta aceita menciona isso, mas não explica por quê.

    

Answer 1

Na plataforma NT, o espaço de endereço virtual de 4 GB é dividido, por padrão, em duas partes, os 2 GB mais baixos para o espaço de endereço do processo e os 2 GB superiores para o uso do sistema.

Este espaço de endereço é virtual e não é influenciado pelo tamanho da RAM. O gerenciador de memória da CPU e do SO mapeia partes da RAM no espaço de endereço virtual, conforme necessário. Isso é muito complexo e não será descrito aqui. Esta foi uma decisão de design feita no interesse do desempenho, segurança e confiabilidade.

Cada processo tem seu próprio espaço de endereço privado de 2 GB, mas existe apenas um espaço de endereço do sistema. Os processos são isolados em seu próprio espaço de endereço privado e não podem ver os outros. Há disposição para compartilhar endereços entre dois ou mais processos, quando necessário. O espaço de endereço do sistema está fora dos limites dos processos normais e é acessível apenas aos componentes no nível do kernel, como o próprio SO e os drivers de dispositivo. Se um processo se desgarra, só pode se machucar; outros processos e o SO não são afetados.

Mas por que não dar ao sistema seu próprio espaço de endereço privado, assim como para os processos? Isso permitiria que o espaço de endereço completo de 4 GB estivesse disponível para o sistema e para cada processo. Isso poderia ter sido feito - mas houve um problema.

Suponha que isso foi feito. O processo em execução teria acesso total ao seu próprio código e dados e tudo pareceria bem. Mas e se esse processo fizer uma chamada de sistema operacional que requeira acesso ao espaço de endereço do sistema, como para uma operação de E / S? Ou o que acontece se houver uma interrupção que precisa ser tratada pelo kernel?

Apenas o espaço de endereço do processo em execução pode ser visto pela CPU. O que fazer? A solução é fazer um comutador de contexto que exiba o espaço de endereço do sistema. O sistema operacional pode fazer isso de forma bastante eficiente, mas leva tempo. Se o espaço de endereço do sistema precisava ser acessado com freqüência, a sobrecarga das chaves de contexto se tornaria excessiva e o desempenho sofreria.

Tinha que haver uma maneira melhor.

A solução adotada era dividir o espaço total de endereços de 4 GB em duas partes de 2 GB cada. Espaço de endereço do processo nos 2 GB mais baixos e o sistema no superior. Isso permite que o espaço de endereço do sistema esteja sempre no escopo e acessível sempre que necessário sem uma alternância de contexto. Como acontece com frequência, as decisões de design são tomadas por razões práticas.

2 GB pode parecer muito pequeno e restritivo agora, mas foi enorme quando o NT foi lançado em 1993. E não se esqueça que cada processo tem seus próprios 2 GB para si.

    

Answer 2

De acordo com o livro Windows Internals, foi uma decisão de design. Eles dividiram todo o espaço de memória virtual de 4 GB em duas partes:

• Espaço de endereço virtual no modo kernel de 2 GB (janelas de memória do driver, etc.)
• Espaço de endereço virtual no modo de usuário de 2 GB (memória para programas do espaço do usuário)

Depois, há a opção /3GB não recomendada (que altera o usuário do kernel 1: 3 e pode levar a erros desagradáveis com drivers que alocam em deslocamentos absolutos), PAE e creio que havia mais uma API que, quando usada, permite alocar memória não paginada e dinamicamente abri-la para o espaço de endereços dos programas (mas não consigo lembrar o nome dela) agora).