Como a afinidade da CPU interage com os cgroups no Linux?

Question

Estou tentando executar benchmarks multi-thread em um conjunto de CPUs isoladas. Para encurtar a história, tentei inicialmente com isolcpus e taskset , mas pressione a-multi-thread-linux-program-on-a-set-of-isolated"> . Agora estou jogando com cgroups / csets.

Acho que o "simples" cset shield use-case deve funcionar bem. Eu tenho 4 núcleos, então eu gostaria de usar os núcleos 1-3 para benchmarking (eu também configurei esses núcleos para estar no modo de ticks adaptativos), então o core 0 pode ser usado para todo o resto.

Seguindo o tutorial aqui , deve ser tão simples quanto:

$ sudo cset shield -c 1-3
cset: --> shielding modified with:
cset: "system" cpuset of CPUSPEC(0) with 105 tasks running
cset: "user" cpuset of CPUSPEC(1-3) with 0 tasks running

Então agora temos um "escudo" que é isolado (o usuário cset) e o núcleo 0 é para todo o resto (o sistema cset).

Tudo bem, parece bom até agora. Agora vamos ver htop . Todos os processos devem ter sido migrados para a CPU 0:

Huh? Alguns dos processos são mostrados como sendo executados nos núcleos protegidos. Para descartar o caso de htop ter um bug, também tentei usar taskset para inspecionar a máscara de afinidade de um processo mostrado como estando na blindagem.

Talvez essas tarefas não pudessem ser removidas? Vamos arrancar um processo arbitrário mostrado como rodando em CPU3 (que deveria estar no escudo) em htop e ver se aparece no cgroup do sistema de acordo com cset :

$ cset shield -u -v | grep 864
   root       864     1 Soth [gmain]
   vext01    2412  2274 Soth grep 864 

Sim, que está sendo executado no cgroup do sistema de acordo com cset . Portanto, htop e cset não concordam.

Então, o que está acontecendo aqui? Em quem eu confio: afinidades de CPU ( htop / taskset ) ou cset ?

Eu suspeito que você não deveria usar cset e afinidades juntos. Talvez o escudo esteja funcionando bem e eu deveria ignorar as máscaras de afinidade e htop de saída. De qualquer forma, acho isso confuso. Alguém pode lançar alguma luz?

    

Answer 1

Na documentação do cpusets :

Calls to sched_setaffinity are filtered to just those CPUs allowed in that task's cpuset.

Isso implica que as máscaras de afinidade de CPU são interceptadas com os cpus no cgroup do qual o processo é membro.

Por exemplo Se a máscara de afinidade de um processo incluir núcleos {0, 1, 3} e o processo estiver sendo executado no cgroup do sistema, que é restrito aos núcleos {1, 2}, o processo será forçado a ser executado no núcleo 1.

Tenho 99% de certeza de que a saída htop está "errada" para o fato de os processos não terem despertado desde que os cgroups foram criados, e a exibição está mostrando o núcleo last o processo foi executado.

Se eu começar o vim antes de fazer meu escudo, vim forks duas vezes (por alguma razão), e o filho mais profundo estiver rodando no core 2. Se eu fizer o escudo, então durma vim (ctrl + z) e acorde, ambos os processos mudaram para o núcleo 0. Acho que isso confirma a hipótese de que htop está mostrando informações antigas.

Você também pode inspecionar /proc/<pid>/status e ver os campos cpus_allowed_* .

Por exemplo Eu tenho um console-kit-daemon process (pid 857) aqui mostrando no htop como rodando no core 3, mas em /proc/857/status :

Cpus_allowed:   1
Cpus_allowed_list:      0

Acho que isso está dizendo que a máscara de afinidade é 0x1, que permite a execução apenas no core 1 devido aos cgroups: ie intersect ({0,1,2,3}, {0}) = {0}. / p>

Se eu puder, deixarei a questão aberta por um tempo para ver se surge alguma resposta melhor.

Obrigado ao @davmac por ajudar com isso (no irc).