A principal desvantagem de usar o zram é a inversão LRU :
as páginas mais antigas entram no zram de prioridade mais alta e o preenchem rapidamente, enquanto as páginas mais novas são trocadas dentro e fora do swap [...]
A documentação do zswap diz que o zswap não sofre com isso:
O Zswap recebe páginas para compactação por meio da API do Frontswap e é capaz de remover páginas de seu próprio pool compactado em uma base LRU e escrevê-las de volta no dispositivo de troca de suporte caso o pool compactado esteja cheio.
Eu poderia ter todos os benefícios do zram e uma RAM completamente compactada configurando max_pool_percent
para 100
?
Zswap seeks to be simple in its policies. Sysfs attributes allow for one user controlled policy: * max_pool_percent - The maximum percentage of memory that the compressed pool can occupy.
Nenhum padrão max_pool_percent
é especificado aqui, mas a página Arch Wiki diz que é 20
.
Além das implicações de desempenho da descompactação, existe algum perigo/desvantagem em definir max_pool_percent
para 100
?
Ele funcionaria como um zram aprimorado com suporte de swap?
Para responder à sua pergunta, primeiro fiz uma série de experimentos. As respostas finais estão em negrito no final.
Experimentos realizados:
Configuração antes do experimento:
swappiness
(60)dd
), masswapon
ainda nãowatch "killall -9 dnf"
para ter mais certeza de que o dnf não tentará atualizar automaticamente durante o experimento ou algo assim e jogará os resultados longe demaisEstado antes do experimento:
As operações de swapon subsequentes, etc., levando a configurações diferentes durante os experimentos, resultaram em variações de cerca de 2% desses valores.
A operação do experimento consistiu em:
Declare após o experimento:
1) arquivo de troca, zswap desabilitado
2) arquivo de troca, zswap ativado, max_pool_percent = 20
3) arquivo de troca, zswap ativado, max_pool_percent = 70
4) arquivo de troca, zswap ativado, max_pool_percent = 100
5) troca zram, zswap desabilitado
6) zram swap, zswap ativado, max_pool_percent = 20
7) sem troca
Observe que o firefox não está sendo executado neste experimento no momento do registro dessas estatísticas.
8) arquivo de troca, zswap ativado, max_pool_percent = 1
9) arquivo de troca (300 M), zswap ativado, max_pool_percent = 100
O Firefox estava travado e o sistema ainda lia o disco furiosamente. A linha de base para este experimento é diferente, pois um novo arquivo de troca foi gravado:
Especificamente, 649384 setores extras foram gravados como resultado dessa alteração.
Declare após o experimento:
Subtrair os 649384 setores escritos extras de 2022272 resulta em 1372888. Isso é menor que 1433000 (veja mais adiante), provavelmente porque o firefox não está carregando totalmente.
Também fiz alguns experimentos com
swappiness
valores baixos (10 e 1) e todos eles travaram em um estado congelado com leituras de disco excessivas, impedindo-me de registrar as estatísticas finais da memória.Observações:
max_pool_percent
valores altos resultaram em lentidão.max_pool_percent
resultam na menor quantidade de gravações, enquanto valores muito baixosmax_pool_percent
resultam no maior número de gravações.Setores escritos como consequência direta da troca (aprox.):
Setores extras lidos como consequência direta da troca (aprox.):
Interpretação de resultados:
zswap
, mas evidentemente não é adequado para esta tarefa.Opiniões pessoais e anedotas:
zswap
com os valores padrão deswappiness
emax_pool_percent
sempre se comporta melhor do que qualquerswappiness
valor e nenhumzswap
ouzswap
com valores altos demax_pool_percent
.)swappiness
parecem fazer o sistema se comportar melhor até que a quantidade de cache de página restante seja tão pequena que torne o sistema inutilizável devido a leituras excessivas de disco. Semelhante com muito altomax_pool_percent
.zram
a troca e limite a quantidade de páginas anônimas que você precisa manter na memória ou use a troca com suporte de disco comzswap
valores aproximadamente padrão paraswappiness
emax_pool_percent
.EDIT: Possível trabalho futuro para responder aos pontos mais delicados da sua pergunta seria descobrir para o seu caso de uso específico como o
zsmalloc
alocador usado emzram
compara a compactação com ozbud
alocador usado emzswap
. Não vou fazer isso, apenas apontar coisas para pesquisar em documentos/na internet.EDIT 2:
echo "zsmalloc" > /sys/module/zswap/parameters/zpool
muda o alocador de zswap dezbud
parazsmalloc
. Continuando com meu dispositivo de teste para os experimentos acima e comparandozram
comzswap
+zsmalloc
, parece que, desde que a memória de troca necessária seja a mesma que umazram
troca ou comozswap
,max_pool_percent
a quantidade de leituras e gravações no disco é muito semelhante entre os dois . Em minha opinião pessoal com base nos fatos, desde que a quantidade dezram
swap de que preciso seja menor do que a quantidade dezram
swap que posso realmente manter na RAM, é melhor usar apenaszram
; e quando eu precisar de mais swap do que realmente posso manter na memória, é melhor alterar minha carga de trabalho para evitá-lo ou desabilitar ozram
swap e usarzswap
comzsmalloc
e definirmax_pool_percent
para o equivalente ao que o zram anteriormente ocupava na memória (tamanho dazram
* taxa de compactação). Atualmente, não tenho tempo para escrever adequadamente esses testes adicionais.