询问kthread_create_on_cpu()+wake_up_process()与kthread_run()+kthread_bind()绑核效果是否等价

Great question! Let’s break down how these two approaches work and whether they deliver identical results when pinning a kernel thread to a specific CPU core.

First Approach: kthread_create_on_cpu() + wake_up_process() #

• kthread_create_on_cpu() is built to create a kernel thread already bound to your target CPU from the get-go. Under the hood, it immediately sets the thread's CPU affinity mask to only include the specified core via sched_setaffinity().
• A key detail: this function spawns the thread in a TASK_UNINTERRUPTIBLE (sleeping) state, which is why you need to call wake_up_process() to wake it up and let it start executing.
• Critical guarantee: The thread never gets a chance to run on any other CPU. It’s locked to the target core before it ever schedules its first instruction.

Second Approach: kthread_run() + kthread_bind() #

• Let’s start with kthread_run(): this is a convenience macro that wraps kthread_create() and immediately calls wake_up_process(). By default, the thread it creates has an affinity mask allowing it to run on all available CPUs.
• kthread_bind() then restricts the thread’s affinity to the specified core—but there’s a timing catch:
  • If you call kthread_bind() before the thread is scheduled to run for the first time, it pins the thread to the target core before it ever executes. This gets you almost identical behavior to the first approach.
  • If the thread has already started running (even for a tiny slice of time) before you call kthread_bind(), the kernel will migrate the thread to the target core mid-execution. That means the thread may have already run on other CPUs briefly before being pinned.

Are the Effects Identical? #

• Best-case timing scenario: If you call kthread_bind() right after kthread_run() (before the thread is dispatched by the scheduler), the end result is nearly the same as the first approach. The thread will run exclusively on the target core once it starts.
• Key strictness difference: kthread_create_on_cpu() guarantees zero execution on non-target CPUs. The kthread_run() + kthread_bind() approach has a small window where the thread could run elsewhere if scheduling beats your bind call.
• Implementation nuance: kthread_create_on_cpu() handles affinity setup as part of the creation flow, making it a more atomic pinning operation. The two-step method introduces a tiny bit of timing uncertainty.

Recommendations #

• Use kthread_create_on_cpu() + wake_up_process() if you need absolute certainty that the thread never runs on any core other than your target (e.g., for latency-sensitive workloads).
• Use kthread_run() + kthread_bind() if you prefer the convenience of the kthread_run() macro and can ensure the bind happens before the thread starts executing (e.g., in a context where you control scheduling order tightly).

内容的提问来源于stack exchange，提问作者campescassiano