Systemd-oomd como o daemon out-of-memory originalmente desenvolvido pelo Facebook tem amadurecido muito bem desde a fusão no ano passado e sua implantação mais notável até agora foi com a estreia do Fedora 34 no início deste ano. Anita Zhang do Facebook forneceu uma atualização hoje sobre o esforço systemd-oomd.
Durante a Linux Plumbers Conference (LPC2021) hoje foi feita esta atualização de Anita no systemd-oomd. O Systemd-oomd sendo usado por padrão no Fedora 34 foi um dos grandes impulsionadores deste ano para o projeto. Alguns problemas iniciais já resolvidos com o systemd-oomd giravam em torno dos limites iniciais para iniciar a eliminação de OOM sendo muito baixa, a eliminação de troca sendo muito agressiva e recursos de CPU altos.
Um novo recurso para systemd-oomd está trazendo suporte em torno de configurações para unidades de usuário. Essa solicitação de pull foi mesclada no systemd ontem para oferecer suporte às atualizações de propriedade ManagedOOM da unidade de usuário. Um dos patches explica:
Comparado com PID1 onde systemd-oomd tem que ser o cliente para PID1 porque PID1 é um processo mais privilegiado que systemd-oomd, systemd-oomd é o processo mais privilegiado comparado a um gerenciador de usuários, portanto, temos gerenciadores de usuários como o cliente, enquanto o systemd-oomd é agora o servidor.
O mesmo protocolo varlink é usado entre gerenciadores de usuários e systemd-oomd para entregar atualizações de propriedades do ManagedOOM. systemd-oomd agora configura um servidor varlink ao qual os gerenciadores de usuários se conectam para enviar atualizações de propriedades do ManagedOOM.
Também adicionamos validação extra para garantir que remetentes não-root não enviem atualizações para cgroups que eles não possuem.
Outra área de melhoria é
Mais detalhes sobre o estado do systemd-oomd para o outono de 2021 podem ser encontrados por meio da apresentação de Anita incorporada abaixo (se o YouTube está agitado, começa a cerca de três quartos do fluxo) e este conjunto de slides da apresentação.
