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

Estou tentando executar benchmarks multithread em um conjunto de CPUs isoladas. Para encurtar a história, tentei inicialmente com isolcpuse taskset, mas encontrei problemas . Agora estou jogando com cgroups / csets.

Eu acho que o cset shieldcaso de uso "simples" deve funcionar bem. Eu tenho 4 núcleos, então eu gostaria de usar os núcleos 1-3 para o benchmarking (também configurei esses núcleos para estar no modo de tiques adaptáveis), para que o núcleo 0 possa 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 olhar htop. Todos os processos devem ter sido migrados para a CPU 0:

Hã? Alguns dos processos são mostrados como sendo executados nos núcleos blindados. Para descartar o caso de o htop ter um bug, tentei usar também tasksetpara inspecionar a máscara de afinidade de um processo mostrado como estando no escudo.

Talvez essas tarefas fossem imóveis? Vamos iniciar um processo arbitrário mostrado como sendo executado na CPU3 (que deve estar no escudo) htope ver se ele 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, isso está sendo executado no cgroup do sistema de acordo com cset. Então, htope csetdiscordo.

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

Eu suspeito que você não deve usar csete afinidades juntos. Talvez o escudo esteja funcionando bem, e eu devo ignorar as máscaras de afinidade e a htopsaída. De qualquer maneira, acho isso confuso. Alguém pode lançar alguma luz?

Na documentação dos cpusets :

As chamadas para sched_setaffinity são filtradas apenas para as CPUs permitidas no cpuset dessa tarefa.

Isso implica que as máscaras de afinidade da CPU são cruzadas com as 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 em execução no cgroup do sistema, restrito aos núcleos {1, 2}, o processo será forçado a executar no núcleo 1.

Estou 99% certo de que a htopsaída está "errada", pois os processos não foram despertados desde a criação dos cgroups, e a tela está mostrando o último núcleo em que o processo foi executado.

Se eu iniciar o vim antes de fazer o meu escudo, o vim bifurca-se duas vezes (por algum motivo) e a criança mais profunda estiver executando o núcleo 2. Se eu fizer o escudo, durma o vim (ctrl + z) e ative-o, ambos os processos terão mudou-se para o núcleo 0. Acho que isso confirma a hipótese de htopmostrar informações obsoletas.

Você também pode inspecionar /proc/<pid>/statuse observar os cpus_allowed_*campos.

Por exemplo, eu tenho um console-kit-daemonprocesso (pid 857) aqui mostrando no htop como sendo executado no núcleo 3, mas em /proc/857/status:

Cpus_allowed:   1
Cpus_allowed_list:      0

Eu acho que isso está dizendo que a máscara de afinidade é 0x1, o que permite rodar apenas no núcleo 1 devido aos cgroups: ie intersect ({0,1,2,3}, {0}) = {0}.

Se eu puder, deixarei a pergunta em aberto por um tempo para ver se há alguma resposta melhor.

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