我已经使用cpuset来屏蔽某些实时线程专用的cpus。
使用testing应用程序RealtimeTest1运行并将其任务移动到cpusets中显示cpusetconfiguration：
$ 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文件系统来显示我的任务应该固定在我请求的cpus上：
/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作用 – 即thread1在cpu 3上，thread2在cpu 5上。
但是，如果我用f,j运行top -p 17649 -H来调出last used cpu ，则表明线程1正在线程2的cpu上运行，而主线程正在system cpuset中的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不工作？
我的机器configuration是：
$ 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
更新：
另外，我正在parsing/proc/pid/task/tid/stat并在cset --move调用之前和之后调用sched_getcpu() ，并且在locking之后还要执行sched_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的问题吗？
我已经在SLES 11 / SP 2盒上重新进行了testing，并且locking工作。
因此，我将把这个标记作为答案，即：这是与SP 1相关的问题