O que há de "quebrado" na semântica de herança do cpuset cgroup no kernel do Linux?

Eu não sou bem versado o suficiente com cgroups para dar uma resposta definitiva (e eu certamente não tenho experiência com cgroups desde 2013!), mas em um Ubuntu 16.04 baunilha cgroups v1 parece agir em conjunto:

Eu criei um pequeno teste que força a bifurcação como um usuário diferente usando um filho sudo /bin/bashdesmembrado &- o -Hsinalizador é uma paranóia extra para forçar sudoa execução com o ambiente inicial do root.

cat <(whoami) /proc/self/cgroup >me.cgroup && \
sudo -H /bin/bash -c 'cat <(whoami) /proc/self/cgroup >you.cgroup' & \
sleep 2 && diff me.cgroup you.cgroup

Isso rende:

1c1
< admlocal
---
> root

Para referência, esta é a estrutura das montagens do cgroup no meu sistema:

$ mount | grep group
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
lxcfs on /var/lib/lxcfs type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
$

Pelo menos um problema definitivo e não resolvido com cpusets está documentado no rastreador de bugs do kernel aqui:

Bug 42789 - cpuset cgroup: quando um CPU fica offline, ele é removido de todos os cpuset.cpus do cgroup, mas quando ele fica online, ele só é restaurado para o cpuset.cpus root

Para citar um comentário do ticket (estou adicionando os hiperlinks aos commits reais e removendo o endereço de e-mail da IBM no caso de spambots):

Isso foi relatado independentemente por Prashanth Nageshappa... e corrigido no commit 8f2f748b0656257153bcf0941df8d6060acc5ca6 , mas posteriormente revertido por Linus como commit 4293f20c19f44ca66e5ac836b411d25e14b9f185 . De acordo com seu commit, a correção causou regressões em outros lugares.

O commit de correção (que foi posteriormente revertido) descreve bem o problema:

Atualmente, durante o hotplug da CPU, os retornos de chamada do cpuset modificam os cpusets para refletir o estado do sistema, e esse tratamento é assimétrico. Ou seja, na CPU offline, essa CPU é removida de todos os cpusets. No entanto, quando ele volta a ficar online, ele é colocado de volta apenas no cpuset raiz.

Isso dá origem a um problema significativo durante a suspensão/retomada. Durante a suspensão, desconectamos todos os cpus que não são de inicialização e, durante a retomada, os colocamos on-line novamente. O que significa que, após um resumo, todos os cpusets (exceto o cpuset root) serão restritos a apenas uma única CPU (a CPU de inicialização). Mas todo o objetivo de suspender/retomar é restaurar o sistema para um estado o mais próximo possível de como estava antes da suspensão.

O mesmo problema de hotplug assimétrico é descrito com mais informações sobre como ele se relaciona com a herança, em:

Bug 188101 - o agendamento do processo no cpuset do cgroup não está funcionando corretamente.

Citando esse bilhete:

Quando o cpuset de um contêiner (docker/lxc usa o cgroup subjacente) fica vazio (devido ao hotplug/hotunplug), os processos em execução nesse contêiner podem ser agendados em qualquer cpus no cpuset de seu ancestral não vazio mais próximo.

Mas, quando o cpuset de um contêiner em execução (docker/lxc) se torna não vazio de um estado vazio (adicionando cpu ao cpuset vazio) atualizando o cpuset do contêiner em execução (usando o método echo), os processos em execução nesse contêiner ainda usa o mesmo cpuset de seu ancestral não vazio mais próximo.

Embora possa haver outros problemas com o cpuset, o que foi dito acima é suficiente para entender e entender a afirmação de que o systemd não expõe ou utiliza o cpuset "devido à semântica de herança quebrada da lógica do kernel".

A partir desses dois relatórios de bugs, não apenas as CPUs não são adicionadas de volta a um cpuset após o reinício, mas mesmo quando são adicionados (manualmente), os processos nesse cgroup ainda serão deixados em execução em CPUs potencialmente não permitidas pelo cpuset.

Encontrei uma mensagem de Lennart Poettering que confirma diretamente isso como o motivo (negrito adicionado):

Em quarta-feira, 03/08/2016 às 16:56 +0200, Lennart Poettering escreveu:

Na quarta-feira, 03.08.16 14:46, Dr. Werner Fink (werner em suse.de) escreveu:

problema com v228 (e acho que isso também é posterior ao AFAICS dos logs do git atual) que repete eventos de hotplug da CPU (offline/online). A causa raiz é que o cpuset.cpus não foi restaurado por usinado. Observe que o libvirt não pode fazer isso, pois não é permitido.

Esta é uma limitação da interface do kernel cpuset, e é uma das razões pelas quais não expomos cpusets no systemd agora. Felizmente, há uma alternativa aos cpusets, que são os controles de afinidade da CPU expostos via CPUAffinity= no systemd, que fazem o mesmo, mas têm semântica menos borked.

Gostaríamos de oferecer suporte a cpusets diretamente no systemd, mas não fazemos isso desde que as interfaces do kernel sejam tão borked quanto são. Por exemplo, cpusets são totalmente liberados atualmente quando o sistema passa por um ciclo de suspensão/retomada.

O que há de "quebrado" na semântica de herança do cpuset cgroup no kernel do Linux?

"Observe que o número de atributos de cgroup atualmente expostos como propriedades de unidade é limitado. Isso será estendido mais tarde, à medida que suas interfaces de kernel forem limpas. Por exemplo, cpuset ou freezer não estão expostos atualmente devido à semântica de herança quebrada do lógica do kernel . Além disso, a migração de unidades para uma fatia diferente em tempo de execução não é suportada (ou seja, alterando a propriedade Slice= para unidades em execução), pois o kernel atualmente não possui movimentos de subárvore de cgroup atômicos."

Então, o que há de errado com a semântica de herança da lógica do kernel para cpuset (e como essa falha não se aplica a outros controladores de cgroup, como cpu)?

A citação em negrito acima é preocupante. Para colocar de outra forma, quais são as "pegadinhas" (armadilhas) que podem se aplicar ao uso do cgroup v1 cpuset que estão sendo referenciados aqui?

Resposta realmente curta: O código não é multiprocessado bem, diferentes processos usam e liberam PIDs retornando-os ao pool antes que os PIDs de seus filhos terminem - deixando o upstream acreditar que os filhos do PID estão ativos, então pule esse PID, mas esse PID não deveria ter sido reeditado antes de encerrar as crianças. Em suma, fechaduras pobres.

Serviços, escopos e slices podem ser criados livremente pelo administrador ou dinamicamente por programas. Isso pode interferir na configuração de slices padrão pelo sistema operacional durante a inicialização.

Com Cgroups um processo e todos os seus filhos extraem recursos do grupo que o contém.

E muito mais... levando a uma longa resposta...

Várias pessoas expressaram suas preocupações:

1. " Os grupos de controle do Linux não são trabalhos " (2016) por Jonathan de Boyne Pollard:

   Um kernel do sistema operacional que fornece uma abstração de "trabalho" fornece uma maneira de cancelar/eliminar um "trabalho" inteiro. Testemunhe o mecanismo Win32 TerminateJobObject() , por exemplo.

   Quando o systemd encerra todos os processos em um cgroup, ele não emite uma única chamada de sistema "terminate job". Não existe tal coisa. Em vez disso , ele fica em um loop no código do modo de aplicativo, verificando repetidamente todos os IDs de processo no cgroup (relendo um arquivo cheio de números PID) e enviando sinais para novos processos que não viu antes. Existem vários problemas com isso.

   • systemd pode ser mais lento do que o que está colhendo processos filhos dentro do grupo de processos, levando os sinais de término a serem enviados para o processo completamente errado: um que acabou de reutilizar o mesmo ID de processo entre o systemd lendo o arquivo de lista de processos do cgroup e na verdade, ele está enviando sinais para a lista de processos. ...

   ...

   • Um programa que bifurca novos processos com rapidez suficiente dentro do cgroup pode manter o systemd girando por um longo tempo, em teoria indefinidamente, desde que o "clima" adequado prevaleça, pois em cada iteração de loop haverá mais um processo para matar. Observe que isso não precisa ser uma bomba de garfo. Ele só precisa bifurcar o suficiente para que o systemd veja pelo menos mais um novo ID de processo no cgroup toda vez que executar seu loop.

   • O systemd mantém os IDs dos processos que já sinalizou em um conjunto, para saber para quais não tentará enviar sinais novamente. É possível que um processo com ID N possa ser sinalizado, finalizado e removido da tabela de processos por um reaper/pai; e então algo dentro do cgroup bifurca um novo processo que recebe o mesmo ID de processo N mais uma vez. O systemd irá reler a lista de IDs do processo do cgroup, pensará que já sinalizou o novo processo e não o sinalizará de forma alguma.

    

   Estes são abordados por um verdadeiro mecanismo de "trabalho". Mas os cgroups não são assim. cgroups foram concebidos como uma melhoria sobre os mecanismos tradicionais de limite de recursos do Unix, abordando algumas de suas falhas de design de longa data e bem conhecidas. Eles não foram projetados para serem equivalentes a um VMS ou a um Objeto de Trabalho do Windows NT .

   Não, o freezer não é a resposta. Não apenas o systemd não usa o freezer, mas as pessoas do systemd o descrevem explicitamente como tendo " semântica de herança quebrada da lógica do kernel ". Você terá que perguntar a eles o que eles querem dizer com isso , mas o freezer também não transforma magicamente os cgroups em um mecanismo de trabalho.

   Além disso: isso sem mencionar que o Docker e outros manipularão o status de congelamento dos grupos de controle para seus próprios propósitos, e não há um mecanismo real livre de corrida para compartilhar essa configuração entre vários proprietários, como uma leitura e atualização atômica por isso.
   _{É concedida permissão para copiar e distribuir esta página da Web em sua forma original e não modificada, desde que o carimbo de data da última modificação seja preservado.}

   • Função TerminateJobObject()

     Terminates all processes currently associated with the job. If the  
     job is nested, this function terminates all processes currently  
     associated with the job and all of its child jobs in the hierarchy. 
     

   • Objetos de trabalho do Windows NT

     A job object allows groups of processes to be managed as a unit.  
     Job objects are namable, securable, sharable objects that control  
     attributes of the processes associated with them. Operations  
     performed on a job object affect all processes associated with the  
     job object. Examples include enforcing limits such as working set   
     size and process priority or terminating all processes associated 
     with a job.
     

   A resposta oferecida na explicação de Jonathan é:

   Conceitos de controle de recursos do systemd

   ...

   Unidades de serviço, escopo e fatia mapeiam diretamente para objetos na árvore do cgroup. Quando essas unidades são ativadas, cada uma delas mapeia diretamente (módulo de algum caractere escapando) para caminhos de cgroup construídos a partir dos nomes das unidades. Por exemplo, um serviço quux.service em uma fatia foobar-waldo.slice é encontrado no cgroup foobar.slice/foobar-waldo.slice/quux.service/.

   Serviços, escopos e slices podem ser criados livremente pelo administrador ou dinamicamente por programas. No entanto, por padrão, o sistema operacional define vários serviços internos necessários para inicializar o sistema. Além disso, há quatro fatias definidas por padrão: primeiro a fatia raiz -.slice (como mencionado acima), mas também system.slice, machine.slice, user.slice. Por padrão, todos os serviços do sistema são colocados na primeira fatia, todas as máquinas virtuais e contêineres na segunda e as sessões de usuário na terceira. No entanto,isso é apenas um padrão, e o administrador pode definir livremente novas fatias e atribuir serviços e escopos a elas. Observe também que todas as sessões de login são colocadas automaticamente em uma unidade de escopo individual, assim como os processos de VM e contêiner. Por fim, todos os usuários que fizerem login também obterão uma fatia implícita própria onde todos os escopos de sessão são colocados .

   ...

   Como você pode ver, serviços e escopos contêm processos e são colocados em fatias, e as fatias não contêm processos próprios. Observe também que o "-.slice" especial não é mostrado, pois está implicitamente identificado com a raiz da árvore inteira.

   Os limites de recursos podem ser definidos em serviços, escopos e fatias da mesma maneira. ...

Siga os links acima para a explicação completa.

2. " Cgroups v2: gerenciamento de recursos feito ainda pior na segunda vez " (14 de outubro de 2016), por davmac:

   ...

   Você pode criar uma hierarquia aninhada de modo que haja grupos dentro de outros grupos e os grupos aninhados compartilhem os recursos de seu grupo pai (e podem ser ainda mais limitados). Você move um processo para um grupo gravando seu PID em um dos arquivos de controle do grupo. Portanto, um grupo contém potencialmente processos e subgrupos.

   Os dois recursos óbvios que você pode querer limitar são memória e tempo de CPU, e cada um deles tem um “controlador”, mas existem potencialmente outros (como largura de banda de E/S), e alguns controladores Cgroup não gerenciam realmente a utilização de recursos como tal (por exemplo, o controlador/subsistema “congelador”). A interface Cgroups v1 permitia a criação de múltiplas hierarquias com diferentes controladores anexados a elas (o valor disso é duvidoso, mas a possibilidade existe).

   É importante ressaltar que os processos herdam sua associação ao cgroup de seu processo pai e não podem sair (ou entrar) em um cgroup a menos que tenham privilégios apropriados, o que significa que um processo não pode escapar de suas limitações que lhe foram impostas por bifurcação. Compare isso com o uso de setrlimit, onde o uso de memória de um processo (por exemplo) pode ser limitado usando uma limitação RLIMIT_AS (espaço de endereço), mas o processo pode bifurcar e seus filhos podem consumir memória adicional sem usar os recursos do original processo. Com Cgroups, por outro lado, um processo e todos os seus filhos extraem recursos do grupo que o contém.

   ...

   Os controladores do cgroup implementaram vários botões que nunca seriam aceitos como APIs públicas porque estavam apenas adicionando botões de controle ao pseudo sistema de arquivos de gerenciamento de sistema. O cgroup acabou com botões de interface que não foram adequadamente abstraídos ou refinados e revelaram detalhes internos do kernel diretamente.

   Esses botões foram expostos a aplicativos individuais por meio do mecanismo de delegação mal definido, abusando efetivamente do cgroup como um atalho para implementar APIs públicas sem passar pelo escrutínio necessário.

   ...

   O cgroup v1 permitia que as threads estivessem em qualquer cgroups, o que criava um problema interessante onde as threads pertencentes a um cgroup pai e seus cgroups filhos competiam por recursos. Isso foi desagradável, pois dois tipos diferentes de entidades competiam e não havia uma maneira óbvia de resolver isso. Diferentes controladores fizeram coisas diferentes.

3. Veja também os documentos do cgroup v2: " Problemas com v1 e Rationales for v2 ":

   Várias hierarquias

   O cgroup v1 permitia um número arbitrário de hierarquias e cada hierarquia poderia hospedar qualquer número de controladores. Embora isso parecesse fornecer um alto nível de flexibilidade, não era útil na prática.

   Por exemplo, como há apenas uma instância de cada controlador, controladores do tipo utilitário, como freezer, que podem ser úteis em todas as hierarquias, só podem ser usados ​​em um. O problema é agravado pelo fato de que os controladores não podem ser movidos para outra hierarquia depois que as hierarquias forem preenchidas. Outro problema era que todos os controladores vinculados a uma hierarquia eram forçados a ter exatamente a mesma visão da hierarquia. Não foi possível variar a granularidade dependendo do controlador específico.

   Na prática, esses problemas limitavam fortemente quais controladores poderiam ser colocados na mesma hierarquia e a maioria das configurações recorria a colocar cada controlador em sua própria hierarquia. Apenas aqueles intimamente relacionados, como os controladores cpu e cpuacct, faziam sentido serem colocados na mesma hierarquia. Isso geralmente significava que o userland acabava gerenciando várias hierarquias semelhantes, repetindo as mesmas etapas em cada hierarquia sempre que uma operação de gerenciamento de hierarquia era necessária.

   Além disso, o suporte para várias hierarquias teve um custo exorbitante. Isso complicou muito a implementação do núcleo do cgroup, mas mais importante ainda, o suporte para várias hierarquias restringiu como o cgroup poderia ser usado em geral e o que os controladores eram capazes de fazer.

   Não havia limite de quantas hierarquias poderiam existir, o que significava que a associação do cgroup de um encadeamento não podia ser descrita em tamanho finito. A chave podia conter qualquer número de entradas e era ilimitada em comprimento, o que tornava muito difícil de manipular e levava à adição de controladores que existiam apenas para identificar a associação, o que por sua vez exacerbou o problema original de proliferação do número de hierarquias.

   Além disso, como um controlador não pode ter nenhuma expectativa em relação às topologias de hierarquias em que outros controladores podem estar, cada controlador teve que assumir que todos os outros controladores foram anexados a hierarquias completamente ortogonais. Isso tornou impossível, ou pelo menos muito complicado, que os controladores cooperassem entre si.

   Na maioria dos casos de uso, não é necessário colocar controladores em hierarquias completamente ortogonais entre si. O que geralmente é exigido é a capacidade de ter diferentes níveis de granularidade dependendo do controlador específico. Em outras palavras, a hierarquia pode ser recolhida da folha para a raiz quando vista de controladores específicos. Por exemplo, uma determinada configuração pode não se importar com como a memória é distribuída além de um determinado nível enquanto ainda deseja controlar como os ciclos de CPU são distribuídos.

Consulte o link da seção 3 para obter mais informações.

4. Comunicação entre Lennart Poettering (systemd Developer) e Daniel P. Berrange (Redhat) em Wed, 20.07.16 12:53 recuperada dos arquivos systemd-devel intitulado: " [systemd-devel] Confining ALL process to a CPUs/RAM via cpuset controlador ":

   Na quarta-feira, 20.07.16 12:53, Daniel P. Berrange (berrange em redhat.com) escreveu:

   Para hosts virtualizados, é bastante comum querer confinar todos os processos do SO do host a um subconjunto de nós de CPUs/RAM, deixando o restante disponível para uso exclusivo do QEMU/KVM. Historicamente, as pessoas usaram o kernel "isolcpus" arg para fazer isso, mas no ano passado isso teve sua semântica alterada, de modo que quaisquer CPUs listadas lá também sejam excluídas do balanceamento de carga pelo schedular, tornando-o bastante inútil em casos de uso geral não em tempo real onde você ainda deseja que os threads QEMU tenham balanceamento de carga entre as CPUs.

   So the only option is to use the cpuset cgroup controller to confine procosses. AFAIK, systemd does not have an explicit support for the cpuset controller at this time, so I'm trying to work out the "optimal" way to achieve this behind systemd's back while minimising the risk that future systemd releases will break things.

   On Wed, Jul 20, 2016 at 03:29:30PM +0200, Lennart Poettering replied:

   Yes, we don't support this as of now, but we'd like to. The thing though is that the kernel interface for it is pretty borked as it is right now, and until that's not fixed we are unlikely going to support this in systemd. (And as I understood Tejun the mem vs. cpu thing in cpuset is probably not going to stay the way it is either).

   Next message

   On Wed, 20.07.16 14:49, Daniel P. Berrange (berrange at redhat.com) wrote:

   cgroupsv2 is likely to break many things once distros switch over, so I assume that wouldn't be done in a minor update - only a major new distro release so, not so concerning.

I hope that clarifies things.