☰

cpuset 不工作--线程没有在我指定的 cpuset 中运行？

tag-icon • tag-icon linux scheduler
cpuset 不工作--线程没有在我指定的 cpuset 中运行？

我曾经cpuset屏蔽一些 CPU，以供一些实时线程专用。

显示正在运行的测试应用程序的 cpuset 配置RealtimeTest1及其移入 cpuset 的任务：

$ cset set --list -r
cset: 
         Name         CPUs-X    MEMs-X Tasks Subs Path
 ------------   ---------- - ------- - ----- ---- ----------
         root         0-23 y     0-1 y   279    2 /
       system 0,2,4,6,8,10 n       0 n   202    0 /system
       shield 1,3,5,7,9,11 n       1 n     0    2 /shield
RealtimeTest1      1,3,5,7 n       1 n     0    4 /shield/RealtimeTest1
      thread1            3 n       1 n     1    0 /shield/RealtimeTest1/thread1
      thread2            5 n       1 n     1    0 /shield/RealtimeTest1/thread2
         main            1 n       1 n     1    0 /shield/RealtimeTest1/main

我可以查询cpuset文件系统来表明我的任务是据称固定到我请求的 CPU：

/cpusets/shield/RealtimeTest1 $ for i in `find -name tasks`; do echo $i; cat $i; echo "------------"; done

./thread1/tasks
17651 
------------
./main/tasks
17649 
------------
./thread2/tasks
17654
------------

此外，如果我使用sched_getaffinity，它会报告什么cpuset- 线程 1 在 CPU 3 上，而线程 2 在 CPU 5 上。

但是，如果我运行top -p 17649 -H以f,j调出last used cpu，则表明线程 1 在线程 2 的 CPU 上运行，主线程在systemcpuset中的 CPU 上运行

（请注意，线程 17654 正在运行 FIFO，因此线程 17651 被阻塞）

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND                                                                                                                                                                                             
17654 root      -2   0 54080  35m 7064 R  100  0.4   5:00.77 3 RealtimeTest                                                                                                                                                                                         
17649 root      20   0 54080  35m 7064 S    0  0.4   0:00.05 2 RealtimeTest                                                                                                                                                                                         
17651 root      20   0 54080  35m 7064 R    0  0.4   0:00.00 3 RealtimeTest

另外，查看/proc/17649/task其last_cpu每个任务的运行情况：

/proc/17649/task $  for i in `ls -1`; do cat $i/stat | awk '{print $1 " is on " $(NF - 5)}'; done
17649 is on 2
17651 is on 3
17654 is on 3

因此cpuset，sched_getaffinity报道是一回事，但现实是另一回事

我会说这cpuset不起作用？

我的机器配置是：

$ cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 1
$ uname -a
Linux foobar 2.6.32.12-0.7-default #1 SMP 2010-05-20 11:14:20 +0200 x86_64 x86_64 x86_64 GNU/Linux

更新：

此外，我在调用之前和之后进行解析/proc/pid/task/tid/stat和调用，并且我还在固定之后进行尝试让线程移动......sched_getcpu()cset --movesched_yield()

这是一个示例输出：

13:12:56 INFO before pinning thread 17508 reports lastCpu=0, currCpu=1
13:12:56 INFO pinning thread 17508 to cpu 3 (/shield/RealtimeTest1/thread1)
13:12:56 INFO SetAffinity cset response:
    cset: moving following pidspec: 17508
    cset: moving 1 userspace tasks to /shield/RealtimeTest1/thread1
    cset: done
13:12:56 INFO after pinning thread 17508 reports lastCpu=0, currCpu=1
13:12:56 INFO after sch_yld thread 17508 reports lastCpu=0, currCpu=1

因此线程不会立即移动到新的 cpuset，甚至不会在sched_yield

这可能是 SLES 11 / SP 1 的问题吗？

答案1

我已经重新进行了测试SLES 11 / SP 2盒子，并固定作品。

因此，我将把这个标记为答案，即：这是一个与SP 1

相关内容