我在 Ubuntu 机器（14.04 LTS）上以服务器模式运行 iperf。硬件是具有超线程的四核，因此我有可用的核心 0-7（0 与 4 配对，1 与 5 配对，依此类推）。
我已将正在运行的 iperf 进程的处理器关联设置为仅使用处理器 0,1。我可以使用任务集验证这一点：
$ taskset -pc 27745
pid 27745's current affinity list: 0,1
如果我在 top 或 htop 中查看该进程，则该进程会正确显示为仅在这些核心之一上运行。但是，如果我切换到线程视图，那么我会看到子线程在任意核心上运行。
top/htop 是否以某种方式误导了我？这真的会发生吗？如果是这样，为什么以及如何预防？
编辑
我应该评论说，虽然我在 iperf 中看到了这一点，但我并不一定意味着它是 iperf 特定的。这恰好是我的设置。如果我无法弄清楚这一点，那么我可能会尝试其他可执行文件，看看该行为是否可重现。
答案1
我已经了解了这件事的真相（某种程度上）。这要归功于我从 ansible 启动 iperf 的不寻常方式。最初我没有发现 iperf 有守护进程模式 ( -D)，所以我手动启动 iperf daemon。我已经忘记了这一点，也没有时间去改变它。
奇怪的是，如果我使用此方法启动 iperf，那么它似乎会立即产生一些额外的线程。请注意，我并不是指daemon必须启动子进程才能正确分离子进程（即确保它不是进程组领导者，而是进程组的子进程init等）。 iperf 进程本身一旦启动就会启动一些额外的线程（除非这确实是运行的一个方面daemon- 但根据 ，它们确实看起来是线程htop）。
我正在taskset对守护进程和 iperf 进程进行良好的测量，但我想这错过了子线程（请参阅此处以获取有关此问题的讨论：设置正在运行的进程与任务集的关联性失败）。我不相信这就是完整的故事，因为我没有看到主要的 iperf 进程在正确的处理器上运行，所以有些可疑的事情正在发生。我相信这可以通过更好地调查 的行为来解释，daemon但我现在没有时间调查，所以我就到此为止。