Bagaimana cara afinitas CPU berinteraksi dengan cgroup di Linux?

Saya mencoba menjalankan benchmark multi-threaded pada satu set CPU yang terisolasi. Singkat cerita, saya awalnya mencoba isolcpusdan taskset, tetapi mengalami banyak masalah . Sekarang saya bermain dengan cgroups / csets.

Saya pikir kasus penggunaan "sederhana" cset shieldharus bekerja dengan baik. Saya memiliki 4 core, jadi saya ingin menggunakan core 1-3 untuk benchmarking (saya juga mengkonfigurasi core ini untuk berada dalam mode ticks adaptif), maka core 0 dapat digunakan untuk yang lainnya.

Mengikuti tutorial di sini , seharusnya sesederhana:

$ 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

Jadi sekarang kita memiliki "tameng" yang terisolasi (cset pengguna) dan inti 0 untuk yang lainnya (cset sistem).

Baiklah, sejauh ini terlihat bagus. Sekarang mari kita lihat htop. Semua proses harus dimigrasi ke CPU 0:

Hah? Beberapa proses ditunjukkan berjalan di inti terlindung. Untuk mengesampingkan kasus bahwa htop memiliki bug, saya juga mencoba menggunakan tasksetuntuk memeriksa topeng afinitas dari suatu proses yang ditunjukkan berada dalam perisai.

Mungkin tugas-tugas itu tidak bergerak? Mari kita memetik proses sewenang-wenang yang ditunjukkan berjalan pada CPU3 (yang seharusnya ada di dalam perisai) htopdan lihat apakah itu muncul di cgroup sistem menurut cset:

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

Yap, itu berjalan pada sistem cgroup menurut cset. Jadi htopdan csettidak setuju.

Jadi apa yang terjadi di sini? Siapa yang saya percayai: cpu afinities ( htop/ taskset) atau cset?

Saya curiga bahwa Anda tidak seharusnya menggunakan csetdan kedekatan bersama. Mungkin perisai bekerja dengan baik, dan saya harus mengabaikan topeng afinitas dan htopoutput. Either way, saya menemukan ini membingungkan. Adakah yang bisa menjelaskan?

Dari dokumentasi cpusets :

Panggilan ke sched_setaffinity difilter ke CPU yang diizinkan dalam cpuset tugas itu.

Ini menyiratkan bahwa topeng afinitas CPU berpotongan dengan CPU di cgroup yang prosesnya menjadi anggota.

Misalnya, jika topeng afinitas dari suatu proses menyertakan core {0, 1, 3} dan proses tersebut berjalan pada system cgroup, yang dibatasi untuk core {1, 2}, maka proses akan dipaksa untuk berjalan pada core 1.

Saya 99% yakin bahwa htopoutputnya "salah" pada kenyataan bahwa prosesnya belum terbangun sejak cgroup dibuat, dan tampilan menunjukkan inti terakhir dari proses yang dijalankan.

Jika saya mulai vim sebelum membuat perisai saya, vim bercabang dua kali (untuk beberapa alasan), dan anak yang paling dalam berjalan pada core 2. Jika saya kemudian membuat perisai, kemudian tidur vim (ctrl + z) dan bangunkan, kedua proses memiliki pindah ke inti 0. Saya pikir ini mengkonfirmasi hipotesis yang htopmenunjukkan informasi basi.

Anda juga dapat memeriksa /proc/<pid>/statusdan melihat cpus_allowed_*bidang.

Misalnya saya punya console-kit-daemonproses (pid 857) di sini ditampilkan di htop sebagai berjalan pada core 3, tetapi di /proc/857/status:

Cpus_allowed:   1
Cpus_allowed_list:      0

Saya pikir ini mengatakan bahwa topeng afinitas adalah 0x1, yang memungkinkan berjalan hanya pada inti 1 karena cgroup: yaitu berpotongan ({0,1,2,3}, {0}) = {0}.

Jika saya bisa, saya akan membiarkan pertanyaan terbuka beberapa saat untuk melihat apakah ada jawaban yang lebih baik.

Terima kasih kepada @davmac untuk membantu dengan ini (di irc).