Primeiro, a quantidade de RAM que precisa ser salva é surpreendentemente pequena. De fato, apenas o conjunto de páginas sujas mapeadas ("write-back lento") precisa ser liberado, assim como todas as páginas particulares que foram gravadas e o código executável realocado precisam ser gravadas.
- Os segmentos .text dos executáveis são sempre apoiados pelo mapeamento de arquivos. Isso também é verdade para pelo menos algumas DLLs (mas não todas, depende se elas precisam ser realocadas).
- A memória que é apoiada de maneira semelhante por mapeamentos de arquivos pode ser descartada (presume-se que não seja CoW ou RW e esteja sujo).
- O write-back preguiçoso ainda precisará ocorrer, mas, além disso, os caches podem ser descartados.
- A memória alocada, mas não gravada (geralmente a maior parte dos dados do aplicativo!) É suportada pela página zero e pode ser descartada.
- A maior parte das páginas de memória que estão no status "em espera" (o conjunto de trabalho real por processo residente no Windows é surpreendentemente pequeno, meros 16 MB) será copiado para o arquivo de paginação em segundo plano em algum momento e poderá ser descartado .
- Regiões da memória mapeadas por determinados dispositivos, como a placa gráfica, podem (possivelmente) não precisar ser salvas. Às vezes, os usuários ficam surpresos ao conectar 8GiB ou 16GiB a um computador, e 1GiB ou 2GiB simplesmente "desaparecem" sem motivo aparente. As principais APIs gráficas exigem que os aplicativos possam tornar o conteúdo do buffer inválido "sob algumas condições" (sem dizer exatamente o que isso significa). Portanto, não é irracional esperar que a memória fixada pelo driver gráfico também seja descartada. Afinal, a tela ficará escura de qualquer maneira.
Segundo, ao contrário de você copiar um arquivo, despejar o conjunto de páginas de RAM que precisam ser salvas em disco é uma única gravação sequencial e contígua do ponto de vista da unidade. A API do Win32 até expõe uma função no nível do usuário para essa mesma operação. O Gather Write é suportado diretamente pelo hardware e funciona tão rápido quanto o disco é capaz de aceitar dados fisicamente (o controlador extrai dados diretamente via DMA).
Existem várias condições prévias para que isso funcione (como alinhamento, tamanho do bloco, fixação), e ele não funciona bem com o armazenamento em cache e não existe "write-back lento" (que é uma otimização muito desejável em operação normal) )
Essa é a razão pela qual nem toda gravaçãofunciona assim o tempo todo. No entanto, quando o sistema está salvando o arquivo de hibernação, todas as pré-condições são atendidas automaticamente (todos os dados são alinhados, dimensionados e fixados) e o armazenamento em cache tornou-se irrelevante porque o computador será desligado em um momento.
Terceiro, fazer uma única gravação contígua é muito favorável tanto para discos giratórios quanto para discos de estado sólido.
O arquivo de troca e o arquivo de hibernação são geralmente alguns dos arquivos mais antigos criados e reservados no disco. Eles geralmente têm um, no máximo dois fragmentos. Portanto, a menos que os setores estejam danificados e o disco precise realocar os setores físicos, uma gravação sequencial lógica será convertida em uma gravação sequencial física em um disco rotativo.
Nenhuma operação de leitura-modificação-gravação é necessária no disco quando uma grande quantidade de dados sequenciais e contíguos está sendo gravada. Esse problema é menos pronunciado em discos rígidos giratórios, que podem gravar setores únicos muito pequenos (desde que você não grave bytes únicos, o que o cache geralmente impede, o dispositivo não precisará buscar o conteúdo original e gravar a versão modificada). .
Isso é, no entanto, algo que é muito perceptível no SSD, onde cada gravação significa que, por exemplo, um bloco de 512kB (que é um número usual, mas pode ser maior) deve ser lido e modificado pelo controlador e gravado em um arquivo diferente. quadra. Embora você possa, em princípio, escrever para (mas não substituir)) unidades menores em discos flash, você só pode apagar blocos enormes, é assim que o hardware funciona. Essa é a razão pela qual os SSDs se saem muito melhor em gravações sequenciais enormes.