| Red Hat Enterprise Linux 4: Introdução à Administração de Sistemas | ||
|---|---|---|
| Anterior | Capítulo 4. Memória Física e Virtual | Próxima |
Apesar da tecnologia por trás da construção de várias tecnologias de armazenamento atuais ser muito impressionante, o administrador de sistemas mediano não precisa saber dos detalhes. De fato, há somente uma questão que os administradores de sistemas precisam ter em mente:
Nunca há memória RAM suficiente.
Apesar desta evidência parecer humorística, muitos desenvolvedores de sistemas operacionais levaram bastante tempo tentando reduzir o impacto desta deficiência real. Eles implementaram a memória virtual — uma maneira de combinar RAM com armazenamento mais lento para dar a um sistema a impressão de ter mais memória RAM do que realmente há instalada.
Vamos começar com uma aplicação hipotética. O código da máquina criando esta aplicação tem tamanho de 10000 bytes. Também requer outros 5000 bytes para armazenamento de dados e buffers de I/O. Isto significa que, para rodar esta aplicação, deve haver 15000 bytes de RAM disponíveis. Se houver um byte a menos, a aplicação não será executada.
Este requisito de 15000 bytes é conhecido como o espaço de endereço da aplicação. É o número de endereços únicos necessários para armazenar ambos, a aplicação e seus dados. Nos primeiros computadores, a quantidade de RAM disponível tinha que ser maior que o espaço de endereço da maior aplicação a rodar; caso contrário, a aplicação falharia com um erro de "falta de memória".
Uma última tática, conhecida como sobreposição (overlaying), tentou amenizar o problema permitindo que programadores ditassem quais partes de sua aplicação precisavam estar residindo na memória em uma determinada hora. Desta maneira, o código necessário uma vez para propósitos de inicialização pôde ser sobreposto (overlayed) com código que seria utilizado mais tarde. Apesar da sobreposição ter facilitado a redução de memória, era um processo muito complexo e suscetível a erros. As sobrepopsições também falharam em resolver a questão da redução de memória de todo o sistema no tempo de execução (runtime). Em outras palavras, um programa sobreposto pode precisar de menos memória para rodar que um programa não sobreposto, mas se o sistema ainda não tiver memória suficiente para o programa sobreposto, o resultado final é o mesmo — um erro de falta de memória.
A memória virtual altera o conceito do espaço de endereço de uma aplicação. Ao invés de concentrar no quanto de memória uma aplicação precisa para rodar, um sistema operacional com memória virtual tenta continuamente responder à pergunta: "quão pequena é a memória precisa para rodar uma aplicação?"
Apesar de, à primeira vista, parecer que nossa aplicação hipotética precisa de 15000 bytes para rodar, pense em nossa abordagem na Seção 4.1 — o acesso à memória tende ser sequencial e localizado. Por este motivo, a quantidade de memória precisa para executar a aplicação numa determinada hora é menor que 15000 bytes — geralmente muito menor. Considere os tipos de acessos à memória necessários para executar uma única instrução da máquina:
As instruções são lidas da memória.
Os dados necessários pelas instruções são acessados da memória.
Após completar as instruções, os resultados das instruções são gravados de volta na memória.
O número real de bytes necessários para cada acesso à memória varia de acordo com a arquitetura da CPU, com as instruções em si e com o tipo de dados. No entanto, mesmo se uma instrução precisasse de 100 bytes de memória para cada tipo de acesso à memória, os 300 bytes necessários seriam bem menos que todo o espaço de endereço de 15000 bytes da aplicação. Se pudermos encontrar uma maneira de manter o registro das necessidades de memória de uma aplicação enquanto roda, poderíamos manter a aplicação rodando enquanto usaríamos menos memória que aquela ditada pelo seu espaço de endereço.
Mas isso nos traz uma pergunta:
Se somente uma parte da aplicação está na memória em uma determinada hora, onde está o resto dela?
A resposta rápida para esta pergunta é que o resto da aplicação continua no disco. Em outras palavras, o disco atua como o backing store da RAM; um meio de armazenamento maior e mais lento atuando como um "backup" de um meio de armazenamento menor e mais rápido. À primeira vista, isto pode parecer um grande problema de desempenho — acima de tudo, os drives de disco são bem mais lentos que a RAM.
Apesar disso ser verdade, é possível tirar proveito do comportamento de acesso sequencial e localizado das aplicações e eliminar a maioria das implicações do uso de drives de disco como backing store da memória RAM. Isto é feito ao estruturar o sub-sistema da memória virtual, para que tente garantir que aquelas partes da aplicação necessárias no momento — ou que, provavelmente, serão necessárias no futuro próximo — sejam mantidas na RAM somente enquanto forem realmente necessárias.
De muitas maneiras, isso é parecido com a relação entre a memória cache e a memória RAM: fazer com que uma pequena quantidade de armazenamento rápido junto à uma grande quantidade de armazenamento lento atuem como uma grande quantidade de armazenamento rápido.
Com isso em mente, vamos explorar o processo mais detalhadamente.