Restaurando o estado da página na memória / trocado na continuação da hibernação

Question

Sou um grande fã do suporte de hibernação do Linux, que funciona muito bem em todo o hardware (reconhecidamente um pouco mais antigo) em que já experimentei. Eu prefiro que desligue completamente e ligue.

Há uma coisa sobre a hibernação que me incomodou por um tempo: um sistema hibernado é sempre lento e não responde imediatamente depois de ter sido retomado. Não é mal-humorado imediatamente depois de ligado. Isso é exacerbado pelo hardware antigo, mas também acontece em sistemas mais recentes em uma extensão ligeiramente notável.

Isto parece ser porque o kernel apenas troca as páginas criticamente necessárias para a operação [kernel-level] de volta à memória de trabalho, restaura o estado de trabalho base do kernel e deixa o userspace apenas se movimentar por um tempo enquanto vários processos trocam as páginas precisam de volta para a RAM sob seu próprio vapor.

Isso não funciona muito bem na prática, já que o sistema inicialmente funciona como se algum processo grande tivesse forçado tudo a trocar completamente pelo disco. O que quer que estivesse na tela irá voltar rapidamente, mas mude para outro processo e você estará esperando alguns segundos, pois o ele também é inserido na memória. No hardware mais antigo - o meu caso é um Core 2 ThinkPad T60 - "alguns segundos" pode até acabar sendo alguns minutos.

Recentemente, percebi que esse problema tem uma solução surpreendentemente simples, depois de pensar um pouco sobre isso: anote as tags que rotulam quais páginas estão no disco e na RAM e restaure esse estado exato no currículo. Claro, o processo de retomada pode levar ~ 10 segundos a mais, mas eu não ligo - eu teria um sistema rápido.

Eu queria saber se há alguma opção de compilação do kernel obscura que permita tal funcionalidade, ou alguma configuração que eu possa configurar que aproxime esse comportamento?

NOTA: não considero swapoff -a; swapon -a uma solução viável; No momento em que o espaço de usuário suspenso é reanimado, todos os processos carregados estão tentando executar código e lutando para se trocar de volta na RAM, causando I / O de disco massivo. A tentativa de destruir a área de troca só aumentaria o furacão e levaria mais tempo para ser concluída do que se o kernel tivesse retomado todo da RAM antes de reanimar o espaço do usuário.