Como é o conteúdo da tabela de páginas depois que uma página foi trocada para o disco?

1

Pelo que entendi, a tabela de páginas mapeia endereços virtuais para endereços físicos. Mas e se uma página foi trocada para o disco? A localização dos dados não precisaria de mais bits para anotar do que o endereço físico? A localização dos dados não muda quando o arquivo de troca é modificado? Este problema é resolvido de maneiras diferentes em diferentes sistemas operacionais?

    
por Deckel 28.11.2015 / 20:22

1 resposta

1

Vamos primeiro fazer a pergunta mais fácil:

Doesn't the location of the data change when the swap file is modified?

Não há modificação do arquivo de paginação que faz com que a localização dos dados existentes seja alterada. Se um arquivo de paginação for estendido, mais clusters (agrupados em "extensões" ou "execuções") serão simplesmente adicionados ao seu final, portanto, a localização dos dados existentes não será alterada. Os locais do arquivo de paginação são sempre relativos ao início de um arquivo de paginação, portanto, mesmo que as extensões já existentes fossem de alguma forma movidas, os locais do arquivo de paginação não seriam alterados.

Agora, sobre os bits:

Wouldn't the location of the data take more bits to write down than the physical address ?

Sim, se o arquivo de paginação puder ser maior que o tamanho da memória física possível, você precisaria de mais bits para especificar uma página no arquivo de paginação do que bits para especificar um número de página física.

Em x86 sem PAE ativado, há 20 bits na entrada da tabela de páginas (PTE) para o número da página física (PFN, abreviação de "número do quadro de página"). (PTEs são 32 bits. Os outros 12 são bits de sinalização, sendo o bit 0 o bit "válido" ou "presente de página" que indica que você não obterá uma falha de página ao fazer referência à página. Três dos bits de sinalização são reservados para uso pelo sistema operacional Outros têm significados como "somente leitura", "acessível apenas no modo kernel", "desabilitar cache", etc.) (Tudo neste parágrafo é determinado pela arquitetura da CPU - é independente do sistema operacional.)

No Windows, os mesmos bits no PTE que contêm o PFN para uma página válida são, de fato, para uma página que está no arquivo de paginação, de fato usada para armazenar o arquivo location-within-page. Isso é expresso como um deslocamento, em unidades de tamanho de página, desde o início do arquivo de paginação. Isso limita os arquivos de paginação a 4 GB, assim como o PFN de 20 bits para páginas físicas limita a RAM a 4 GB nesses sistemas.

No entanto, você pode ter vários arquivos de paginação. Há mais quatro bits no PTE que, para uma página em um arquivo de paginação, indicam o número do arquivo de paginação. Assim, pode haver 16 arquivos de paginação, para um total de 64 GB de espaço de arquivo de paginação possível.

Quando você ativa o PAE nos processadores antigos x86, os PTEs ficam com 64 bits de largura e a CPU implementa 24 bits (acima de 20) do PFN no PTE. Isso permite 64 GB de RAM e, no Windows, 64 GB de arquivos de paginação. Há muitos bits não usados nesse formato PTE, portanto, um sistema operacional poderia realmente suportar arquivos de paginação maiores; Não tenho certeza se o Windows de 32 bits funciona.

Nos processadores de 64 bits mais recentes no modo de 64 bits, há 40 bits de PFN e, novamente, os mesmos bits são usados para manter o deslocamento do arquivo de paginação para páginas inválidas (ou seja, não presentes). Então, RAM ou arquivo de paginação, podemos descrever 2 ^ 40 páginas - isso é um "trilhão binário" de páginas, 1024 para o quarto. E cada página é de 4 KiB. Portanto, um arquivo de paginação de 4 PiB é o máximo e também o máximo de RAM suportado pelo hardware. E, novamente, o Windows diz que você pode ter vários arquivos de paginação. Não acho que teremos limites de espaço no arquivo de paginação tão cedo. :)

Todos os itens acima que não são impostos pela CPU são específicos do sistema operacional. Na verdade, não há razão para que o arquivo location-within-page tenha que ser armazenado no PTE; outra estrutura poderia ser usada. Em processadores como o PowerPC que usam uma tabela de páginas com hash, o SO não pode armazená-lo no PTE, uma vez que um PTE inválido não é armazenado na estrutura do HPT.

Mas no x86 / x64 não há realmente nenhuma razão para não usar o PTE inválido. Isso funciona, a propósito, porque quando o bit "válido" é claro, a MMU não liga para um bit (trocadilho intencional) sobre o resto do PTE. Portanto, para PTEs inválidos, todos, exceto um bit, estão disponíveis para o sistema operacional usar da maneira que preferir. No Windows, na verdade, existem várias outras formas de "PTE inválido", dependendo do estado da página. Para uma página na lista de espera ou modificada, por exemplo, o campo PFN ainda contém a localização física da página na RAM. Um PTE para uma página inválida pode se referir a um "descritor de endereço virtual" ou, se for uma página compartilhada, a um "protótipo de PTE". O hardware MMU nunca vê uma dessas estruturas, apenas PTEs.

Detalhes completos estão no capítulo "Gerenciamento de Memória" do Windows Internals por Solomon, Russinovich e Ionescu.

    
por 30.11.2015 / 20:01