Posso imaginar na verdade dois locais:
- No espaço do kernel pertencente ao processo cuja memória RAM está sendo trocada de entrada/saída
- A partir de
[kswapd0]
No entanto, pesquisando na fonte do kswapd ( mm/vmscan.c
, init/main.c
), pude encontrar: kswapd é de thread único e é iniciado em um único thread. (Exceto em sistemas NUMA, onde todas as regiões de memória têm um kswapd diferente. Mas a maioria dos PCs comuns não são sistemas NUMA.)
No entanto, a partir de agora temos um problema. Podemos supor que o disco é muito mais lento que a memória, por isso não precisamos de um kswapd multi-thread para lidar com a E/S do disco. Mas não é esse o caso se precisarmos utilizar também a camada zswap interna. Particularmente a partir de taxas de compactação mais fortes (desinflar), a CPU pode e provavelmente será um gargalo.
Mas kswapd é single-thread.
É verdade?
Está sendo planejado algum kswapd multi-thread? É realmente necessário?
Ps eu encontrei este tópico na lista de discussão do kernel do linux. Trata-se de uma sugestão de patch rejeitada, o que poderia ter ativado o kswapd multi-thread em sistemas não NUMA. Eles estão falando sobre tudo, exceto esse problema do zswap. Talvez não seja relacionado.
Ps2. Contexto:
- Eu tenho um sistema Linux altamente sobrecarregado de ram (os processos estão usando muito mais ram do que fisicamente disponível).
- A contagem dos processos executados simultaneamente é muito menor do que os núcleos da CPU.
- Estou usando intensamente o zswap.
- Nesse ambiente, seria muito útil usar todos os núcleos de CPU disponíveis para compactar/descompactar páginas de memória . Minha melhor estimativa atual é que a compactação/descompactação da página está sendo feita por
[kswapd0]
, que é um único thread do kernel. Estou investigando as opções para utilizar todos os núcleos da CPU para compactação/descompactação. Essencialmente, seria uma forma de transformar a capacidade restante da CPU para compensar a falta de memória física.
Depois de pesquisar muito, acho que encontrei a resposta.
A compactação real está sendo feita no arquivo
[kswapd]
.O escritor do e-mail de rejeição no tópico citado mostra que a pessoa responsável tinha pelo menos algum motivo pelo qual não comunicou, mas é mais provável que ele simplesmente não soubesse do zswap.
Instalei a sugestão de patch no meu sistema. Faz
kswapd
multi-thread, ou seja, pode comprimir a memória em todos os núcleos da CPU. O patch funciona como charme e causa uma melhoria significativa nos ambientes zswap-ping.A prova: sobrecarreguei massivamente meu sistema (qemu com grande consumo de memória + um compressor pxz), tanto a memória quanto a CPU. Depois disso, vejo isso no
top
:Sim, também significa o seguinte:
Os parâmetros zswap que usei no meu ambiente de teste foram os seguintes (podem ser configurados em
/sys/modules/zswap/parameters
):