因此，如果我使用以下方法设置进程的 CPU 关联性:
sched_setaffinity()
然后使用该进程执行其他一些系统调用，该系统调用是否也保证在 sched_setaffinity 强制执行的同一 CPU 上执行？
本质上，我试图强制一个进程及其发出的系统调用在同一个核心上执行。显然，我可以使用 sched_setaffinity() 强制用户空间代码仅在一个 CPU 上执行，但是同一个系统调用是否强制该进程上下文中的内核空间代码也将在同一个核心上执行？/p>
谢谢!
最佳答案
系统调用实际上只是从用户模式切换到内核模式的进程代码。正在运行的任务根本没有改变，只是暂时进入内核模式执行系统调用，然后返回用户模式。
任务可以被调度程序抢占并移动到不同的 CPU，这可能发生在正常用户模式代码中间，甚至可能发生在系统调用中间。
通过使用 sched_setaffinity() 将任务亲和性设置为单个 CPU，您可以消除这种可能性，因为即使任务被抢占，调度程序也别无选择，只能让它在同一 CPU 上运行CPU(当然，它可能会更改当前正在运行的任务，但当您的任务恢复时，它仍将位于同一 CPU 上)。
所以回答你的问题:
does that same system call enforce kernel-space code in that process context will execute on the same core as well?
是的，确实如此。
现在，地址 @Barmar的评论:对于可以“ sleep ”的系统调用，这并不意味着如果关联性不允许，任务可以更改 CPU。
当系统调用休眠时会发生什么，只是系统调用代码告诉调度程序:“嘿，我在等待某件事，只需在等待时运行另一个任务，稍后再唤醒我”。当系统调用恢复时，它会检查请求的资源是否可用(它甚至可以准确地告诉内核何时它想要被唤醒)，如果没有，它要么再次等待，要么返回用户代码说“抱歉，我什么也没得到，请再试一次”。当然，可以通过某些中断来使资源可用，从而导致中断处理程序在不同的 CPU 上运行，但这是一个不同的故事，而且并不重要。简而言之:中断代码根本不在进程上下文中运行。对于执行系统调用的任务而言，当执行恢复时，资源就神奇地出现了。
关于linux - CPU 亲和性是否在系统调用之间强制执行？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/61218410/