In che modo l'affinità della CPU interagisce con i cgroup in Linux?

Sto cercando di eseguire benchmark multi-thread su un set di CPU isolate. Per farla breve, inizialmente ho provato con isolcpuse taskset, ma ho riscontrato problemi . Ora sto giocando con cgroups / cset.

Penso che il "semplice" cset shieldcaso d'uso dovrebbe funzionare bene. Ho 4 core, quindi vorrei usare i core 1-3 per il benchmarking (ho anche configurato questi core per essere in modalità tick adattabili), quindi il core 0 può essere usato per tutto il resto.

Seguendo il tutorial qui , dovrebbe essere semplice come:

$ 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

Quindi ora abbiamo uno "scudo" che è isolato (l'utente cset) e il nucleo 0 è per tutto il resto (il sistema cset).

Bene, finora sembra buono. Adesso diamo un'occhiata htop. Tutti i processi avrebbero dovuto essere migrati sulla CPU 0:

Eh? Alcuni processi sono mostrati come in esecuzione sui nuclei schermati. Per escludere il caso in cui htop abbia un bug, ho anche provato a usare tasksetper ispezionare la maschera di affinità di un processo mostrato come nello scudo.

Forse quei compiti erano immobili? Innalziamo un processo arbitrario mostrato come in esecuzione su CPU3 (che dovrebbe essere nello scudo) htope vediamo se appare nel cgroup di sistema in base a cset:

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

Sì, è in esecuzione sul cgroup di sistema secondo cset. Quindi, htope csetin disaccordo.

Quindi cosa sta succedendo qui? Di chi mi fido: affinità cpu ( htop/ taskset) o cset?

Ho il sospetto che non dovresti usare csete affinità insieme. Forse lo scudo funziona bene e dovrei ignorare le maschere di affinità e l' htopoutput. Ad ogni modo, lo trovo confuso. Qualcuno può far luce?

Dalla documentazione di cpusets :

Le chiamate a sched_setaffinity vengono filtrate solo per quelle CPU consentite nel cpuset di quell'attività.

Ciò implica che le maschere di affinità della CPU sono intersecate con il cpus nel cgroup di cui fa parte il processo.

Ad esempio, se la maschera di affinità di un processo include core {0, 1, 3} e il processo è in esecuzione sul cgroup di sistema, che è limitato ai core {1, 2}, il processo sarebbe costretto a funzionare sul core 1.

Sono sicuro al 99% che l' htopoutput è "sbagliato" per il fatto che i processi non si sono risvegliati da quando sono stati creati i cgroups e il display mostra l' ultimo core su cui è stato eseguito il processo.

Se inizio vim prima di creare il mio scudo, vim forchette due volte (per qualche motivo) e il bambino più profondo è in esecuzione sul core 2. Se poi creo lo scudo, dormo vim (ctrl + z) e lo riattivo, entrambi i processi hanno spostato al nucleo 0. Penso che ciò confermi l'ipotesi che htopsta mostrando informazioni non aggiornate.

Puoi anche ispezionare /proc/<pid>/statuse guardare i cpus_allowed_*campi.

Ad esempio, ho un console-kit-daemonprocesso (pid 857) che mostra in htop come in esecuzione sul core 3, ma in /proc/857/status:

Cpus_allowed:   1
Cpus_allowed_list:      0

Penso che questo stia dicendo che la maschera di affinità è 0x1, che consente l'esecuzione su solo il core 1 a causa dei cgroups: ie intersect ({0,1,2,3}, {0}) = {0}.

Se posso, lascerò la domanda aperta per un po 'per vedere se arriva una risposta migliore.

Grazie a @davmac per l'aiuto (su irc).