From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.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 0CEEB30D401 for ; Mon, 15 Jun 2026 05:40:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781502005; cv=none; b=FFfeyI6SgsUqm3hoFiimqNGVTU0vgSKv0Mrgc6g2vea0cEiCgHzOiG9vx9dLkmd7qpyuV04/QHTLNAjt5woqUe/MeTp+3OvVaBbAMpdcmq+yXT26Ev+5zljVI2AD5xdRDn7Q9TFht4lgt7VxD5bhtX+CLCzyb2L3R6Bbegt1g2I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781502005; c=relaxed/simple; bh=ts1Y/bRa4/iQXYG1I7tmiQ9NKCiZJ48Pd2FNsI/NDIQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=YMBUBYDPDxw8HAm4MR9wAYUDclW4Opv0SXW7YJRfziYzKFRy5StUWPIJag3tu8wHFYsNc0zSueEqdvXYzE8LrzWVIqTUrIMJvuU4S9Ky86OPUWaNcosNX/19+O+TuSHp8+3HGlZ1HWffKAcKpb6nUim/xI+50P0/6nbBq5K9O5o= 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=ZitHTDFm; arc=none smtp.client-ip=117.135.210.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="ZitHTDFm" 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=Sy 2n8MhJgXezIyErJ3c6f+AJ+Gs03nwU6f6xvFHHljE=; b=ZitHTDFmcHTah31QTc 09oH3ST00242uq0xD3aMq3plaaUAssc6sj9zEYxHElk/OVop0Nv3FJjxdIV2kC1T l5aq3BvwOfuVD3S45TFcvFFsg3XOjX4VRZmAsbx5ZZSc68vUeuZs/FiSY7sc+gKj Qgp0dJ6CAWf18nsiBfqwYizKo= Received: from zhaoxin-MS-7E12.. (unknown []) by gzga-smtp-mtada-g1-3 (Coremail) with SMTP id _____wBnL5rDjy9qlau_DA--.132S4; Mon, 15 Jun 2026 13:38:22 +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 2/2] sched/fair: Simplify balance_interval reset logic in sched_balance_rq() Date: Mon, 15 Jun 2026 13:38:09 +0800 Message-Id: <20260615053809.3587677-3-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--.132S4 X-Coremail-Antispam: 1Uf129KBjvJXoWxWr4fJF18CF4DCF1DWrW8Crg_yoW5Wry3pF Z093y0yr1DKa45t392yF1kZry7Ww47GrnrCF1kGr45Ar15G34Sqr4Fg3y3WF4UCrnYk3Wa v342q348ua4ktrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zRjZXrUUUUU= X-CM-SenderInfo: pmdfy650fxxiqzyzqiywtou0bp/xtbC5w59h2ovj85o+gAA3F In sched_balance_rq(), it is possible to call need_active_balance() twice in quick succession, which is not appropriate. There are two conditions in sched_balance_rq() that reset balance_interval to min_interval, one is when the local variable active_balance is 0, and the other is when need_active_balance() returns a non-zero value. The local variable active_balance is initialized to 0. Therefore, the only situation in which balance_interval can be reset to min_interval is if need_active_balance() has been executed once, marking the local variable active_balance as 1, and then the second call to need_active_balance() returns 0. In other words, the case is that during the interval between two close calls to need_active_balance(), busiest rq completes the recently dispatched active balance stop work, which is quite rare. There are mainly two scenarios that lead to reaching sched_balance_rq(): one is the newly idle balance triggered by __schedule(), and the other is the periodic balance logic controlled by sd->balance_interval or nohz.next_balance, which ultimately executes in the softirq context. The vast majority of cases executing sched_balance_rq() in the system fall under the first scenario. During the execution of __schedule(), preemption is disabled, so the interval between two checks of need_active_balance() in this case will not be long. Thus, before applying this patch, balance_interval would only be unlikely to reset to min_interval during the periodic balance logic, which is relatively much more less frequent than newly balance. In the case which is in softirq context, the execution of the two need_active_balance() checks can indeed be preempted by other tasks, leading to a longer interval between the two checks. However, there is no evidence to suggest that not resetting min_interval in these low-probability cases caused by scheduling preemption offers any significant benefits. It would be better to simplify this complex reset logic for balance_interval to an unconditional reset. Signed-off-by: Xin Zhao --- kernel/sched/fair.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 1c5043629..b562a610b 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -13457,10 +13457,8 @@ static int sched_balance_rq(int this_cpu, struct rq *this_rq, sd->nr_balance_failed = 0; } - if (likely(!active_balance) || need_active_balance(&env)) { - /* We were unbalanced, so reset the balancing interval */ - sd->balance_interval = sd->min_interval; - } + /* We were unbalanced, so reset the balancing interval */ + sd->balance_interval = sd->min_interval; goto out; -- 2.34.1