From nobody Mon Dec 1 23:33:43 2025 Received: from mailgw1.hygon.cn (unknown [101.204.27.37]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C8F0524166C for ; Wed, 26 Nov 2025 09:05:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=101.204.27.37 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764147926; cv=none; b=Is1kK/xQO4Nx4gD+SXENPa04yryIg5RlZ3yY6P9yzmb42JcqgQniwWUCVInb6oP/jPA+jA+kbU5/Dj0Qs3oCiWIMWJoC94wjoNOHhSVbIYfiHjElrWwi9ab+h8mIXi6HoBzoxRPt5QIbZNyPbYBYaEBdTKP217rxu0q3V/Y72kE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764147926; c=relaxed/simple; bh=zqObTib3ye52ZfOxuPOwScbbeEkU8fJC4zODBJzy6Bo=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=XfXM+0DsZM5SbKHZW/rEJ34BhoiKqU5tCwhLYMC0oKjlNDV621qxoBzu6FgmcmqPhwDWcWTpaaSEZ3soB70J27FfHc98H8ZOw36FbSiZwQBBu7IadDW5D7ZPjez7I7xGro2RMrfVix+vupDVEjckdrTM/GRlfbdZPVZzmZeDw80= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=hygon.cn; spf=pass smtp.mailfrom=hygon.cn; arc=none smtp.client-ip=101.204.27.37 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=hygon.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=hygon.cn Received: from maildlp2.hygon.cn (unknown [127.0.0.1]) by mailgw1.hygon.cn (Postfix) with ESMTP id 4dGYY23RyTz2Cs0S; Wed, 26 Nov 2025 17:04:54 +0800 (CST) Received: from maildlp2.hygon.cn (unknown [172.23.18.61]) by mailgw1.hygon.cn (Postfix) with ESMTP id 4dGYY15Vhdz1gTY2; Wed, 26 Nov 2025 17:04:53 +0800 (CST) Received: from cncheex04.Hygon.cn (unknown [172.23.18.114]) by maildlp2.hygon.cn (Postfix) with ESMTPS id 20BE73008F73; Wed, 26 Nov 2025 17:00:56 +0800 (CST) Received: from jianyong.hygon.cn (172.19.20.52) by cncheex04.Hygon.cn (172.23.18.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.27; Wed, 26 Nov 2025 17:04:52 +0800 From: Jianyong Wu To: , , , CC: , , , , , , , , Subject: [PATCH] sched/core: avoid calling select_task_rq if bound to one CPU for exec Date: Wed, 26 Nov 2025 17:04:01 +0800 Message-ID: <20251126090401.59698-1-wujianyong@hygon.cn> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: cncheex06.Hygon.cn (172.23.18.116) To cncheex04.Hygon.cn (172.23.18.114) Content-Type: text/plain; charset="utf-8" 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 Signed-off-by: Yibin Liu Signed-off-by: Jianyong Wu --- 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; =20 scoped_guard (raw_spinlock_irqsave, &p->pi_lock) { - dest_cpu =3D p->sched_class->select_task_rq(p, task_cpu(p), WF_EXEC); + if (p->nr_cpus_allowed > 1 && !is_migration_disabled(p)) + dest_cpu =3D p->sched_class->select_task_rq(p, task_cpu(p), WF_EXEC); + else + dest_cpu =3D cpumask_any(p->cpus_ptr); + if (dest_cpu =3D=3D smp_processor_id()) return; =20 --=20 2.43.0