isolcpus - привязка не работает

Я использую изоляцию для изоляции жил. Я хотел бы привязать определенные потоки к ядрам, но это не работает. После связывания потоков потоки перемещаются в разные ядра.

Ядра 13, 14 и 15 изолированы:

$ cat /proc/cmdline
ro root=/dev/mapper/vg0-root rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg0/swaprd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=137M@0M rd_NO_DM  KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=vg0/root rhgb quiet audit=0 intel_idle.max_cstate=0 console=tty0 console=ttyS1,115200 printk.time=1 processor.max_cstate=1 idle=poll biosdevname=0  isolcpus=13-15

top -H -p pgrep -u prusr12 Ser -d 1 показывает следующее: 5017 и 5018 должны были быть связаны с 14 и 15, а 5014 и 5016 должны были быть с 13.

PID  USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+   P COMMAND
5017 prusr12   20   0 1312m 1.1g 1.1g R 99.9  0.9   9:53.93  5 Server-3.10.
5018 prusr12   20   0 1312m 1.1g 1.1g R 99.9  0.9  10:08.88  7 Server-3.10.
5014 prusr12   20   0 1312m 1.1g 1.1g S  0.0  0.9   0:00.40  2 Server-3.10.
5016 prusr12   20   0 1312m 1.1g 1.1g S  0.0  0.9   0:01.04  4 Server-3.10.

Командная строка такая:

sg devuser "taskset -c 13 /releases/3.10.0/bin/Server-3.10.0 -n X -e DEV -p DEFAULT > /logs/ServerDevPR_DEFAULT.out 2>&1 &"

В процессе 4 потока. Я хочу, чтобы основной поток запускался на 13, поэтому набор задач -c 13. Затем создаются два потока, которые привязывают их к 14 и 15. Я вижу, что потоки были привязаны к 14 и 15, но затем они были перемещены на другие ядра. . pthread_setaffinity_np () используется для привязки потоков к ядрам. CpuSet, возвращаемый pthread_getaffinity_np (), содержит: CPU 14 CpuSet, возвращенный pthread_getaffinity_np (), содержал: CPU 15

Сведения о системе:

$ uname -a
Linux host123 2.6.32-573.12.1.el6.x86_64 #1 SMP Mon Nov 23 12:55:32 EST 2015 x86_64 x86_64 x86_64 GNU/Linux

$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                16
On-line CPU(s) list:   0-15
Thread(s) per core:    1
Core(s) per socket:    8
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 63
Stepping:              2
CPU MHz:               3199.847
BogoMIPS:              6399.06
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              20480K
NUMA node0 CPU(s):     0-7
NUMA node1 CPU(s):     8-15

Что могло пойти не так? Спасибо за уделенное время.

2
задан 31 March 2017 в 23:44
1 ответ

Бидејќи работев со изолација на процесорот во минатото, создадов алатка за да ми помогне, бидејќи дознав на потешкиот начин дека е изненадувачки сложено за да се добие тоа како треба. Алатката е достапна тука:

https://github.com/OpenEneaLinux/rt-tools

Тоа е скриптата паррт што треба да ја погледнете и да се инспирирате.

Една забелешка иако: Можеби нема да работи добро заедно со systemd надвор од кутијата, јас едноставно не го тестирав ова.

Но, што се однесува до вашето специфично прашање, претпоставувам дека она што ви треба е да поставите / sys / fs / cgroup / cpuset / cpuset.sched_load_balance до 0 , за да не се дозволи балансирање на оптоварување на SMP. Ова ќе го оневозможи ова за сè, што можеби не е она што го сакате.

Мојата алатка ( паррт ) се обидува да ги подели процесорите во два сета: Една гарнитура што сакате да ја работите како порано и другиот сет кој се обидува да го изолира секој процесор во сетот.

0
ответ дан 3 December 2019 в 14:12

Теги

Похожие вопросы