Grenciamento de memória Linux vs MacOs

Fiz um vídeo do meu setup para que possa ter noção de que é possível ter um sistema bem responsivo, mesmo tendo SWAP e fazendo loucuras com a RAM:

3 Curtidas

Excelente demonstração, @romulopb

O que aquele comando, no terminal, faz?

Explode a sua memória fazendo echo de uma linha com todos os termos de 0 até 1000000000. Se você observar no monitor de memória vai ver minha RAM sendo consumida e posteriormente a SWAP, até o processo ser morto por não ter mais espaço.

Vou colocar um vídeo do MacBook Air também para que você possa ver o comportamento de um atual da Maça:

Melhor maximizar acabei esquecendo de virar o celular :joy:

Também se sai muito bem, excepcionalmente a DE do Mac OS X não engasga sob hipótese alguma para absolutamente nada, mas como podemos ver, alguém precisa pagar essa conta.

  • O Krita começa a dar umas tropeçadas sob alta pressão;
  • A “maximização” de janelas ficou um pouco a desejar devido aos engasgos no conteúdo das mesmas;
  • Podemos ver a demora do echo escalar a RAM, o processo foi propositalmente desacelerado.
  • Precisei gravar no celular, OBS não deu conta de honrar os frames devido a penalização.

Observações finais:

A disparidade de hardware é grande, mas também são as demandas, na workstation o Xorg está carregando uma tela com um total de 5460x3840 (2 monitores), o Mac, 1440x900.
Por fim acho que o Mac faz um trabalho excepcional e acredito que atenda a demanda da maioria do seu público, ter o mínimo possível de engasgos. Mas no meu caso eu prefiro que meu trabalho termine mais rápido para eu ir me divertir, em vez de ser sacrificado pela suavidade das animações. :joy:

2 Curtidas

Obrigado pelas comparações. Foi bastante ilustrativo.

Cuidado, não confunda performance com responsividade.
O Linux pode dar essas “travadas” não por causa da memória, mas sim por causa da CPU.

O Kernel Linux até um tempo atrás não estava pronto para o uso em Desktop, pois o kernel tinha o foco em servidor, ou seja, apenas recentemente o Kernel recebeu atenção para os desktops e começou a otimizá-los.

O “problema” com o Linux no Desktop são as “travadas” e isso se deve à como o sistema gerencia o CPU, o MacOS é campeão nisso e o Linux por default é meio ruim, você pode melhorar (muito) isso usando um Kernel Low-latency e um I/O Scheduler mais focado em Desktop.

Outra coisa interessante de se fazer é reservar um núcleo do CPU apenas para a interface gráfica.

As distros de hoje como O OpenSUSE que é o caso do @Tux já fazem uso da melhor abordagem de IO-scheduler possível, ativam até schedulers blk-mq (Multi-Queue Block IO Queueing Mechanism) quando for necessário. Até uns 2~3 anos atrás fazia sentido dar uma olhada no IO-scheduler, hoje não.

Quanto a um kernel low-latency, é preciso que os programas façam uso. Se.…

  • A DE/distro não tiver feito ajustes no Cgroups da sessão para separar e priorizar adequadamente os processos da sessão;

  • A DE ainda não tiver um compositor com frame timing perfeitamente afinada;

  • O compositor não for preparado para tirar proveito dessa latência baixa;

  • Se o compositor não tiver um suporte maduro ao Wayland;

  • Se tudo isso incluindo o kernel não conversar bem com o driver da GPU e vice-versa.

  • Alguma outra coisa em componentes que lidam com eventos e renderização da DE tiver algum problema…

Um kernel low-latency não vai resolver, e ainda vai queimar throughput. Praticamente todas as distros/máquinas se encontram nesta situação ai de cima, em pelo menos, algum ponto.

Apenas muito recentemente vem sendo feito algo, como investigações no Kwin e Mutter para honrar baixas latências e tempo de entrega dos frames. Tem alguns meses o GNOME ainda estava trabalhando no agendamento e correta separação dos eventos de input no Wayland para threads independentes. Ainda assim faltam muitos ajustes. E nisso tudo ainda nem se materializaram discuções sobre priorização da interface e eventos via CGroups, se é que algo parecido vai ser feito. E nem podemos esquecer que isso é uma realidade meio que limitada ao GNOME ou KDE, muitas outras DEs nem sabem quando vão tocar no Wayland, quem dirá estão revendo o pipeline interno de seus compositores.

Vocês estão a fazer na swap, mas zram não seria melhor para 8gb ou 16 gb incluindo ssd?

Não é bem SWAP, mas sim SWAP em ZRAM, uma variação do ZSWAP. ZRAM pode ser usado ou para isso, ou para a criação de partições na RAM para coisas como /tmp.

Independente da quantidade de RAM que você tiver, alguma SWAP é sempre uma boa ideia, mas se você tem um HDD apenas, são grandes as chances que o sistema sofra engasgos durante o swapping. Neste caso SWAP em ZRAM pode ser uma escolha melhor, você ainda consegue realizar ~50% da capacidade de troca de páginas, sem essa penalidade.

Geralmente é a melhor escolha pois o Linux é relativamente agressivo na gestão de memória, e geralmente é tarde demais para coisas como o compositor sairem ilesos, o que se agrava quando o Kernel precisa esperar um dispositivo lento para abrir espaço.

1 Curtida

Fedora Workstation é o que melhor lida com gerenciamento de memória RAM.

Tive rigorosamente a mesma experiência no popOS em notebook, depois de fazer os mesmos ajustes que fiz no Fedora. Hoje em dia algumas coisas já vem out of box. Esse sistema tem mais de 5 anos instalado e alguns ajustes que fiz apenas na versão 33 e 34 vem recebendo atenção, as grandes distros vem tendo também a mesma abordagem.

Ops parece que há alguma discussão real sobre Melhorias nos agrupamento das sessões via systemd/cgroups:

https://phabricator.kde.org/T12678

Enfim, devagar e sempre, uma hora chegamos lá.