[PATCH] sched/core: avoid calling select_task_rq if bound to one CPU for exec

[PATCH] sched/core: avoid calling select_task_rq if bound to one CPU for exec

[Jianyong Wu]

In the current implementation, even if the task calling execl is bound
to a single CPU (or not allowed to be migrated), it still invokes the
select_task_rq() callback to select a CPU. This is unnecessary and
wastes cycles.

Add a check: if the task is restricted to running on exactly one CPU
(cpus_ptr has only one online CPU) or is not allowed to be migrated,
skip select_task_rq() and directly use the task's bound CPU.

Test environment: 256-CPU X86 server
Test method: Run unixbench's execl test with task bound to a single CPU:

  $ numactl -C 10 ./Run execl -c 1

Test results: Average of 5 runs

baseline    patched    improvement
430.38      437.52     +1.66%

Co-developed-by: Yibin Liu <liuyibin@hygon.cn>
Signed-off-by: Yibin Liu <liuyibin@hygon.cn>
Signed-off-by: Jianyong Wu <wujianyong@hygon.cn>
---
 kernel/sched/core.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index f754a60de848..c1e9f633cfb0 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5442,7 +5442,11 @@ void sched_exec(void)
 	int dest_cpu;
 
 	scoped_guard (raw_spinlock_irqsave, &p->pi_lock) {
-		dest_cpu = p->sched_class->select_task_rq(p, task_cpu(p), WF_EXEC);
+		if (p->nr_cpus_allowed > 1 && !is_migration_disabled(p))
+			dest_cpu = p->sched_class->select_task_rq(p, task_cpu(p), WF_EXEC);
+		else
+			dest_cpu = cpumask_any(p->cpus_ptr);
+
 		if (dest_cpu == smp_processor_id())
 			return;
 
-- 
2.43.0

Re: [PATCH] sched/core: avoid calling select_task_rq if bound to one CPU for exec

[Peter Zijlstra]

On Wed, Nov 26, 2025 at 05:04:01PM +0800, Jianyong Wu wrote:

>  kernel/sched/core.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index f754a60de848..c1e9f633cfb0 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5442,7 +5442,11 @@ void sched_exec(void)
>  	int dest_cpu;
>  
>  	scoped_guard (raw_spinlock_irqsave, &p->pi_lock) {
> -		dest_cpu = p->sched_class->select_task_rq(p, task_cpu(p), WF_EXEC);
> +		if (p->nr_cpus_allowed > 1 && !is_migration_disabled(p))
> +			dest_cpu = p->sched_class->select_task_rq(p, task_cpu(p), WF_EXEC);
> +		else
> +			dest_cpu = cpumask_any(p->cpus_ptr);
> +

Instead of duplicating this, could we not just call select_task_rq()
here?

RE: [PATCH] sched/core: avoid calling select_task_rq if bound to one CPU for exec

[Jianyong Wu]

Hi Peter,

Thanks for reply.

> -----Original Message-----
> From: Peter Zijlstra <peterz@infradead.org>
> Sent: Thursday, November 27, 2025 4:31 PM
> To: Jianyong Wu <wujianyong@hygon.cn>
> Cc: mingo@redhat.com; juri.lelli@redhat.com; vincent.guittot@linaro.org;
> dietmar.eggemann@arm.com; rostedt@goodmis.org; bsegall@google.com;
> mgorman@suse.de; vschneid@redhat.com; linux-kernel@vger.kernel.org;
> jianyong.wu@outlook.com; Yibin Liu <liuyibin@hygon.cn>
> Subject: Re: [PATCH] sched/core: avoid calling select_task_rq if bound to one
> CPU for exec
> 
> On Wed, Nov 26, 2025 at 05:04:01PM +0800, Jianyong Wu wrote:
> 
> >  kernel/sched/core.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c index
> > f754a60de848..c1e9f633cfb0 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -5442,7 +5442,11 @@ void sched_exec(void)
> >  	int dest_cpu;
> >
> >  	scoped_guard (raw_spinlock_irqsave, &p->pi_lock) {
> > -		dest_cpu = p->sched_class->select_task_rq(p, task_cpu(p), WF_EXEC);
> > +		if (p->nr_cpus_allowed > 1 && !is_migration_disabled(p))
> > +			dest_cpu = p->sched_class->select_task_rq(p, task_cpu(p),
> WF_EXEC);
> > +		else
> > +			dest_cpu = cpumask_any(p->cpus_ptr);
> > +
> 
> Instead of duplicating this, could we not just call select_task_rq() here?

Do you mean using select_task_rq() instead of making these changes? I think that works. I'll make this change in the next version.

Thanks
Jianyong