Hello there! I would like to contribute to the project by translating some of the content into Brazilian Portuguese. If you are interested, please let me know and I will work on the other content.
O Linux divide sua RAM física (memória de acesso aleatório) em pedaços de memória chamados páginas. A troca (swap) é o processo em que uma página de memória é copiada para o espaço pré-configurado no disco rígido, chamado espaço de troca, para liberar essa página de memória. O tamanho combinado da memória física e do espaço de troca é a quantidade de memória virtual disponível.
Por que mudei isso?
Ao aumentar o tamanho do swap, podemos fazer algumas coisas:
Reduzir significativamente a pressão sobre a memória
Isso permite que mais dados sejam armazenados em cache e, ao mesmo tempo, permite que a VRAM aumente um pouco mais.
Ter um estoque de "memória de emergência" caso a memória física fique baixa
Isso evita despejos em massa e distribui o gerenciamento de memória por um período mais longo, evitando picos de latência.
O parâmetro swappiness sysctl representa a preferência do kernel (ou evitar) o espaço de swap. O swappiness pode ter um valor entre 0 e 200 (máximo de 100 se o Linux < 5.8), o valor padrão é 60.
Um valor baixo faz com que o kernel evite a troca, um valor alto faz com que o kernel tente usar o espaço de troca e um valor de 100 significa que o custo de IO é considerado igual. O uso de um valor baixo em memória suficiente é conhecido por melhorar a capacidade de resposta em muitos sistemas.
Por que mudei isso?
Por padrão, o Deck tem uma capacidade de troca muito alta de 100, o que pode fazer com que os dados sejam trocados quando há muita memória física restante.
Isso pode ser ruim por dois motivos:
O excesso de gravações pode reduzir a vida útil da unidade
A swap é muito mais lenta do que a memória e seu uso torna tudo mais lento.
Portanto, ao reduzir o swap para um valor mais baixo, ou meu valor recomendado de 1, podemos:
Garantir que a swap seja usada somente no último segundo, quando for realmente necessária
Quando a CPU atribui memória aos processos que a requerem, ela normalmente o faz em pedaços de página de 4 KB.
Como a unidade MMU da CPU precisa traduzir ativamente a memória virtual para a memória física nas solicitações de E/S recebidas, passar por todas as páginas de 4KB é naturalmente uma operação cara. Felizmente, ela tem seu próprio cache TLB (translation lookaside buffer), que reduz o tempo potencial necessário para acessar um endereço de memória específico, armazenando em cache a memória usada mais recentemente.
Por que mudei isso?
Conforme mencionado na explicação, a alocação de páginas é cara. As Hugepages são muito mais fáceis de alocar e procurar, além de reduzirem bastante o gargalo ao lidar com grandes quantidades de memória.
Como isso é feito
echo always | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
A montagem é usada para SysV SHM, memfds, mmaps anônimos compartilhados de (/dev/zero ou MAP_ANONYMOUS), objetos DRM dos drivers de GPU.
Essencialmente, ele permite que essas coisas acabem em hugepages.
Por que mudei isso?
Pelas mesmas razões que a habilitação das hugepages, isso pode reduzir a latência no gerenciamento de memória.
Como isso é feito
echo advise | sudo tee /sys/kernel/mm/transparent_hugepage/shmem_enabled
Proatividade da compactação
O que faz
Esse recurso desfragmenta proativamente a memória quando o Linux detecta "tempo de inatividade".
Por que eu mudei isso?
Até mesmo a documentação do kernel concorda que esse recurso tem um impacto no desempenho de todo o sistema:
Observe que a compactação tem um impacto não trivial em todo o sistema, pois as páginas pertencentes a diferentes processos são movidas, o que também pode levar a picos de latência em aplicativos desavisados.
Essencialmente, mesmo que o Linux tenha tentado detectar o momento adequado para fazer a compactação, nunca há um bom momento durante os jogos, portanto, é melhor desativá-la.
Como é feito
echo 0 | sudo tee /proc/sys/vm/compaction_proactiveness
Desfragmentação da página inicial
O que ela faz
É a mesma coisa que a compactação proativa, mas para hugepages.
Por que mudei isso?
Veja os motivos para desativar a compactação proativa.
Como isso é feito
echo 0 | sudo tee /sys/kernel/mm/transparent_hugepage/khugepaged/defrag
Page Lock Unfairness
O que ele faz
O PLU configura quantas vezes um processo pode tentar obter um bloqueio em uma página antes que o comportamento "justo" entre em ação e garanta o acesso desse processo a uma página.
Infelizmente, ele pode ter efeitos colaterais negativos, especialmente em jogos. O fato de os processos esperarem repetidamente pode fazer com que os jogos tenham muitos problemas com gargalos e faz com que alguns fiquem em estado dormente quando não deveriam.
Como isso é feito
echo 1 | sudo tee /proc/sys/vm/page_lock_unfairness
Fontes
Alguns textos e verificações gerais de sanidade foram fornecidos por Emin, que provavelmente será um grande contribuinte no futuro, dado seu interesse em otimizações de baixo nível do Linux.
O restante foi fornecido por the Arch Wiki, Phoronix,
kernel docs e vários fragmentos de conhecimento que reuni ao longo dos anos.
Hello there! I would like to contribute to the project by translating some of the content into Brazilian Portuguese. If you are interested, please let me know and I will work on the other content.
Explicação dos ajustes
Tamanho do Arquivo de Troca (Swap Size)
O que é é isso?
De acordo com a Wiki do Arch Linux:
Por que mudei isso?
Ao aumentar o tamanho do swap, podemos fazer algumas coisas:
Como é feito
Swappiness
O que ele faz
Também da Wiki do Arch Linux:
Por que mudei isso?
Por padrão, o Deck tem uma capacidade de troca muito alta de 100, o que pode fazer com que os dados sejam trocados quando há muita memória física restante.
Isso pode ser ruim por dois motivos:
Portanto, ao reduzir o swap para um valor mais baixo, ou meu valor recomendado de 1, podemos:
Como isso é feito
Hugepages transparentes
O que ele faz
De um excelente artigo escrito por Emin aqui:
Por que mudei isso?
Conforme mencionado na explicação, a alocação de páginas é cara. As Hugepages são muito mais fáceis de alocar e procurar, além de reduzirem bastante o gargalo ao lidar com grandes quantidades de memória.
Como isso é feito
Memória compartilhada em Hugepages transparentes
O que ele faz
De acordo com a documentação do kernel:
Essencialmente, ele permite que essas coisas acabem em hugepages.
Por que mudei isso?
Pelas mesmas razões que a habilitação das hugepages, isso pode reduzir a latência no gerenciamento de memória.
Como isso é feito
Proatividade da compactação
O que faz
Esse recurso desfragmenta proativamente a memória quando o Linux detecta "tempo de inatividade".
Por que eu mudei isso?
Até mesmo a documentação do kernel concorda que esse recurso tem um impacto no desempenho de todo o sistema:
Essencialmente, mesmo que o Linux tenha tentado detectar o momento adequado para fazer a compactação, nunca há um bom momento durante os jogos, portanto, é melhor desativá-la.
Como é feito
Desfragmentação da página inicial
O que ela faz
É a mesma coisa que a compactação proativa, mas para hugepages.
Por que mudei isso?
Veja os motivos para desativar a compactação proativa.
Como isso é feito
Page Lock Unfairness
O que ele faz
O PLU configura quantas vezes um processo pode tentar obter um bloqueio em uma página antes que o comportamento "justo" entre em ação e garanta o acesso desse processo a uma página.
Consulte the commit para obter mais detalhes.
Por que eu mudei isso?
Infelizmente, ele pode ter efeitos colaterais negativos, especialmente em jogos. O fato de os processos esperarem repetidamente pode fazer com que os jogos tenham muitos problemas com gargalos e faz com que alguns fiquem em estado dormente quando não deveriam.
Como isso é feito
Fontes
Alguns textos e verificações gerais de sanidade foram fornecidos por Emin, que provavelmente será um grande contribuinte no futuro, dado seu interesse em otimizações de baixo nível do Linux.
O restante foi fornecido por the Arch Wiki, Phoronix, kernel docs e vários fragmentos de conhecimento que reuni ao longo dos anos.