From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D841B2857EE for ; Mon, 15 Jun 2026 05:39:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781501993; cv=none; b=Nu7JeLTX1tjT9DpybAuCNDJoz0SZK3dv51tBd8Siu8LBRi+qPX+eY53ExP6xbem7H/QYeOw1M+kUPNCSgdlY3Zi/ARVLwB0OIf4zvpfo2JwMXb0RNzHetPceLlzYO07uaPS21lkOQyVhikjqymxX/fG5Za/A9DjPAcHF7e6+wE0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781501993; c=relaxed/simple; bh=1/fn4RTaNIWM3QIiN1ferAshRQK4GMGxWxY2pIwZ/Yo=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=mg5eIvaDADZxJDyvuqHjmWrvwcXpZqO74giaFcAZUfLF82rO39Lsl8i6gWW+7ca+75C+LMHx1vK9uZDO9To2R3Vp0uFlQ3Pm8hSXJHPoaFyFT6x48VCeTtLhMqe0YWbO77cG8kVtDT5rphpgKpg11XmFbOEOEGFUGJ4PHm9yRa4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=bZ/kuX4t; arc=none smtp.client-ip=220.197.31.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="bZ/kuX4t" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=Jn 8UyCz3xr/54/fLVKxht6rXzLxu6f/cFUsZvGPZCPs=; b=bZ/kuX4tQzJ/psTYbT cYg7ySo6iHcRl8ljIjXX+mp8JEJteAAzm6AnzZFd+KWNFx/jFeRblSHgXpVbOQUO wwjgckRKEe7mcjmafVxs5xzIptQRKvHOiSdkt8CETh/Dz7UBHNsys9Csa/lOO5YS cIXUKVh+Tniw340WHf8UW+mrw= Received: from zhaoxin-MS-7E12.. (unknown []) by gzga-smtp-mtada-g1-3 (Coremail) with SMTP id _____wBnL5rDjy9qlau_DA--.132S3; Mon, 15 Jun 2026 13:38:20 +0800 (CST) From: Xin Zhao To: vschneid@redhat.com, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, kprateek.nayak@amd.com, aiqun.yu@oss.qualcomm.com Cc: linux-kernel@vger.kernel.org, Xin Zhao Subject: [PATCH v3 1/2] sched/fair: Don't trigger active lb if src_rq->curr is CFS and not on_rq Date: Mon, 15 Jun 2026 13:38:08 +0800 Message-Id: <20260615053809.3587677-2-jackzxcui1989@163.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260615053809.3587677-1-jackzxcui1989@163.com> References: <20260615053809.3587677-1-jackzxcui1989@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wBnL5rDjy9qlau_DA--.132S3 X-Coremail-Antispam: 1Uf129KBjvJXoWxZr1DWrWxJrWxZrykXF1xAFb_yoWrAryxpF Wqkr4jgr4kK3WrJan2ka18ZFy8XrsrXayUXas8taySyr45W3Wv9w1Fg3y3GFyUZws8Cr1a ywnrt3y5tw1UKaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0ziOeOJUUUUU= X-CM-SenderInfo: pmdfy650fxxiqzyzqiywtou0bp/xtbC5wx9h2ovj8xowgAA39 Active balancing needs the help by migration threads which will interrupt task on src_rq. It has a certain impact on overall performance. Active balancing often fails, there is a check to determine whether the current task(say it 'curr') on src_rq can run on dst_rq. We have observed that even that, if curr is a CFS task and on_rq is 0, the failure rate of active balancing is very high. Below are the test data from a certain fillback task scenario executed on a platform with 18 CPUs over 300 seconds: total: the total count of cases that match cpumask_test_cpu(this_cpu, busiest->curr->cpus_ptr) && busiest->curr->sched_class == &fair_sched_class && !busiest->curr->on_rq succ/fail: the active balance success/fail cases that match cpumask_......->on_rq total succ fail cpu0 domain0 00003 0 0 0 cpu0 domain1 3ffff 32 0 32 cpu1 domain0 00003 0 0 0 cpu1 domain1 3ffff 40 0 40 cpu2 domain0 0003c 3 0 3 cpu2 domain1 3ffff 6 0 6 cpu3 domain0 0003c 3 1 2 cpu3 domain1 3ffff 3 0 3 cpu4 domain0 0003c 3 0 3 cpu4 domain1 3ffff 4 0 4 cpu5 domain0 0003c 1 0 1 cpu5 domain1 3ffff 6 0 6 cpu6 domain0 003c0 39 0 39 cpu6 domain1 3ffff 36 0 36 cpu7 domain0 003c0 213 4 209 cpu7 domain1 3ffff 24 2 22 cpu8 domain0 003c0 242 16 226 cpu8 domain1 3ffff 16 0 16 cpu9 domain0 003c0 0 0 0 cpu9 domain1 3ffff 6 1 5 cpu10 domain0 03c00 58 1 57 cpu10 domain1 3ffff 0 0 0 cpu11 domain0 03c00 54 4 50 cpu11 domain1 3ffff 1 0 1 cpu12 domain0 03c00 66 1 65 cpu12 domain1 3ffff 0 0 0 cpu13 domain0 03c00 66 1 65 cpu13 domain1 3ffff 0 0 0 cpu14 domain0 3c000 0 0 0 cpu14 domain1 3ffff 57 5 52 cpu15 domain0 3c000 15 0 15 cpu15 domain1 3ffff 35 0 35 cpu16 domain0 3c000 148 3 145 cpu16 domain1 3ffff 109 1 108 cpu17 domain0 3c000 182 2 180 cpu17 domain1 3ffff 78 1 77 In __schedule(), before setting curr to next, during the execution of pick_next_task(), sched_balance_rq() is called. It will unlock and then re-lock the rq, creating "holes" during which other CPUs may see zero rq->curr->on_rq. try_to_block_task() sets curr->on_rq to 0, and during the rq lock "hole" in pick_next_task(), rq->curr has not yet been assigned to next, resulting in curr->on_rq being seen as 0. We do not need to perform active balancing when src_rq->curr is CFS task but on_rq is 0, as other CFS tasks have been already checked just before. For cases where src_rq->curr is a non-CFS task, we retain the affinity check for dst_rq to trigger active balancing because such task is likely to wake-up or woken-by src_rq CFS task which has similar affinity characteristics to migrate. Two reasons why not check sched_class and on_rq of busiest->curr with the cpumask_test_cpu() check: 1. Let the PATCH not introduce new cases that skip logic for resetting balance_interval to min_interval. 2. The check of whether busiest cpu has been just triggered active balance filters a bit more cases than the check of sched_class and on_rq. Signed-off-by: Xin Zhao --- Change in v3: - Consider the cost by sched_class and on_rq check, as suggested by Aiqun(Maira) Yu. Move the check after the check of whether busiest cpu has been just triggered active balance. Change in v2: - Add reason in the commit log why we can see zero rq->curr->on_rq when we hold rq lock, as suggested by Valentin Schneider. - Link to v2: https://lore.kernel.org/all/20260613073228.1951105-1-jackzxcui1989@163.com/ v1: - Link to v1: https://lore.kernel.org/all/20260603125938.1938115-1-jackzxcui1989@163.com/ --- kernel/sched/fair.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index b5819c489..1c5043629 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -13436,7 +13436,9 @@ static int sched_balance_rq(int this_cpu, struct rq *this_rq, * ->active_balance_work. Once set, it's cleared * only after active load balance is finished. */ - if (!busiest->active_balance) { + if (!busiest->active_balance && + !(busiest->curr->sched_class == &fair_sched_class && + !busiest->curr->on_rq)) { busiest->active_balance = 1; busiest->push_cpu = this_cpu; active_balance = 1; -- 2.34.1