[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251127083111.GY3245006@noisy.programming.kicks-ass.net>
Date: Thu, 27 Nov 2025 09:31:11 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Jianyong Wu <wujianyong@...on.cn>
Cc: mingo@...hat.com, juri.lelli@...hat.com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
mgorman@...e.de, vschneid@...hat.com, linux-kernel@...r.kernel.org,
jianyong.wu@...look.com, liuyibin@...on.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?
Powered by blists - more mailing lists