系统调用实际上只是从用户模式切换到内核模式的过程代码。正在运行的任务根本没有改变，它只是暂时进入内核模式来执行系统调用，然后返回到用户模式。
因此，如果我使用设置进程的CPU相关性
sched_setaffinity()
然后使用该进程执行其他系统调用，该系统调用是否也保证在sched_setaffinity强制执行的同一CPU上执行？
从本质上讲，我试图强制一个进程及其进行的系统调用在同一个核心上执行。显然，我可以使用sched_setaffinity()来强制用户空间代码只在一个CPU上执行，但同一个系统调用是否强制该进程上下文中的内核空间代码也会在同一个内核上执行？
谢谢！
任务可以被调度程序抢占并移动到不同的CPU，这可能发生在正常用户模式代码的中间，甚至发生在系统调用的中间。
通过使用sched_setaffinity()将任务相关性设置为单个CPU，可以消除这种可能性，因为即使任务被抢占，调度器也别无选择，只能让它在同一CPU上运行(当然，它可能会更改当前运行的任务，但当任务恢复时，它仍将在同一个CPU上(。
因此，为了回答您的问题：
同一个系统调用是否强制执行该进程上下文中的内核空间代码也将在同一内核上执行？
是的。
现在，为了解决@Barmar的评论：在可以"睡眠"的系统调用的情况下，这并不意味着如果亲和性不允许，任务可以更改CPU。
当系统调用睡眠时会发生什么，只是系统调用代码告诉调度程序："嘿，我正在等待一些事情，只需在等待时运行另一个任务，稍后再唤醒我"。当系统调用恢复时，它会检查请求的资源是否可用(它甚至可以准确地告诉内核它想在被唤醒的时间(，如果没有，它会再次等待或返回用户代码说"对不起，我什么都没有，再试一次"。资源当然可以通过某种中断来提供，这种中断会导致中断处理程序在不同的CPU上运行，但这是另一回事，这并不重要。简单地说：中断代码根本不在进程上下文中运行。就执行系统调用的任务而言，当执行恢复时，资源就神奇地存在了。