TL; DR：渴望CPU的进程在多核服务器上共享核心，而其他核心处于空闲状态，而我期望Linux调度程序在核心之间均匀分配作业。 什么可能导致这种行为？
我的工作组有一个新的运行SuSE的4核服务器，它正在经历一些奇怪的CPU调度行为，我们的pipe理员（设置这个盒子的人）不知道，似乎无法修复。 我希望你们都能帮助我诊断可能导致这种奇怪行为的原因。 这是症状：
1）每个SSH会话似乎都局限于使用单个核心。 我已经testing了多种方法，但最简单的是创build一个简单的无限循环C程序并运行多个副本。 如果从单个SSH会话开始，它们总是共享一个核心，我甚至无法控制哪个核心; 它似乎是在login时设置。 而且，即使使用多个同时进行的SSH会话，我能够以这种方式使用的唯一核心是核心0和核心3; 1和2永远不会感动，无论我开始多less会话或进程。
2）如果从上面提到的SSH会话中，我以“nohup”开始与当前会话分离的程序，它将使用与该会话中启动的其他程序不同的核心。 但是，所有来自同一SSH会话的nohup-started程序都将再次共享一个核心。 有趣的是，这些nohup-started程序总是分配给核心1和核心2。
当然，预期的行为是我在其他Linux系统（我大多熟悉RHEL，Fedora和Ubuntu）时总是看到的：我应该能够在使用或不使用单个会话的情况下使用所有4个内核nohup的; 此外，作业应偶尔跳转核心来平衡它们之间的加载时间。
下面是在一个核心上运行的两个进程的例子： http : //i.imgur.com/K9rH3.png （对不起，不能直接发布图片，即使我在其他StackExchange网站上有足够的信誉）。 请注意，如果单独运行，每个“烧录”进程占用一个内核的100％，但是由于某种原因，这里它们共享一个内核，而三个内核处于空闲状态。 另外请注意，这两个进程共享超过20分钟的“Cpu3”核心，而不改变到另一个核心来平衡负载（这是图像拍摄后，20分钟后，我停止观看）。
当遇到这个问题时，我首先想到的是“ulimit”是有效的，但是对我的（不可否认的）眼睛来说看起来并不是这样：
dmonner@bass:~> ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 128465 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) 13988192 open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 128465 virtual memory (kbytes, -v) 40007280 file locks (-x) unlimited 另外，/etc/security/limits.conf是空的（或者至less没有行不是注释），所以我不认为这是PAM强制执行的限制。
我在机器上有sudo访问权限，即使我“sudo su”然后运行进程，我也是以同样的方式进行核心限制。
那么，有没有人有什么可以引发这种行为的想法，以及如何摆脱它？
Linux调度程序（如果应用程序本身不执行）不会将任何内容绑定到任何特定的内核。 实际上恰恰相反，调度器大多数时候会以一种看似随机的方式将负载反弹到所有核心上。 它是内核中唯一具有整体系统视图的部分，它试图根据一些启发式来“优化”系统响应/吞吐量，这种启发式在本质上performance为内核在内核之间弹跳过程。
你必须通过类似taskset(1)方式明确地把进程taskset(1)到特定的内核来完成这个任务。 你能提供一些你正在经历的证据吗？