Comment l'affinité CPU interagit-elle avec les cgroups sous Linux?

J'essaie d'exécuter des tests de performances multithreads sur un ensemble de processeurs isolés. Pour faire court, j'ai d'abord essayé avec isolcpuset taskset, mais j'ai rencontré des problèmes . Maintenant je joue avec des cgroups / csets.

Je pense que le cset shieldcas d'utilisation "simple" devrait bien fonctionner. J'ai 4 cœurs, je voudrais donc utiliser les cœurs 1 à 3 pour l'analyse comparative (j'ai également configuré ces cœurs pour qu'ils soient en mode ticks adaptatif), puis le cœur 0 peut être utilisé pour tout le reste.

En suivant le tutoriel ici , cela devrait être aussi simple que:

$ 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

Nous avons donc maintenant un "bouclier" qui est isolé (l'utilisateur cset) et le noyau 0 est pour tout le reste (le système cset).

D'accord, semble bon jusqu'à présent. Voyons maintenant htop. Les processus devraient tous avoir été migrés sur la CPU 0:

Hein? Certains processus sont présentés comme s'exécutant sur les cœurs blindés. Pour exclure le cas où htop a un bug, j'ai également essayé d'utiliser tasksetpour inspecter le masque d'affinité d'un processus montré comme étant dans le bouclier.

Peut-être que ces tâches étaient immobiles? Essayons un processus arbitraire montré comme fonctionnant sur CPU3 (qui devrait être dans le bouclier) dans htopet voyons s'il apparaît dans le groupe de contrôle système selon cset:

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

Oui, cela fonctionne sur le groupe de contrôle système selon cset. Alors htopet en csetdésaccord.

Alors qu'est-ce qui se passe ici? En qui ai-je confiance: affinités CPU ( htop/ taskset) ou cset?

Je soupçonne que vous n'êtes pas censé utiliser csetet affinités ensemble. Peut-être que le bouclier fonctionne bien, et je devrais ignorer les masques d'affinité et la htopsortie. Quoi qu'il en soit, je trouve cela déroutant. Quelqu'un peut-il faire la lumière?

De la documentation cpusets :

Les appels à sched_setaffinity sont filtrés uniquement sur les CPU autorisés dans le cpuset de cette tâche.

Cela implique que les masques d'affinité CPU sont intersectés avec les processeurs du groupe de contrôle dont le processus est membre.

Par exemple, si le masque d'affinité d'un processus comprend des cœurs {0, 1, 3} et que le processus s'exécute sur le groupe de contrôle système, qui est limité aux cœurs {1, 2}, alors le processus sera forcé de s'exécuter sur le cœur 1.

Je suis certain à 99% que la htopsortie est "erronée" du fait que les processus ne se sont pas réveillés depuis la création des cgroups, et l'écran affiche le dernier noyau sur lequel le processus a fonctionné.

Si je démarre vim avant de créer mon bouclier, vim fourche deux fois (pour une raison quelconque), et l'enfant le plus profond fonctionne sur le noyau 2. Si je fabrique ensuite le bouclier, puis je dors vim (ctrl + z) et le réveille, les deux processus ont déplacé au noyau 0. Je pense que cela confirme l'hypothèse qui htopmontre des informations périmées.

Vous pouvez également inspecter /proc/<pid>/statuset regarder les cpus_allowed_*champs.

Par exemple, j'ai un console-kit-daemonprocessus (pid 857) montrant ici dans htop comme fonctionnant sur le noyau 3, mais dans /proc/857/status:

Cpus_allowed:   1
Cpus_allowed_list:      0

Je pense que cela signifie que le masque d'affinité est 0x1, ce qui permet de fonctionner uniquement sur le noyau 1 en raison des cgroups: c'est-à-dire intersection ({0,1,2,3}, {0}) = {0}.

Si je peux, je laisserai la question ouverte un moment pour voir si une meilleure réponse apparaîtra.

Merci à @davmac pour votre aide (sur irc).