From nobody Mon Jun 8 07:26:14 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.3]) (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 4BFA73D45C5 for ; Wed, 3 Jun 2026 13:01:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.3 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780491674; cv=none; b=qnd7bQ06c4ungvhuIwFt3vJWnXLNQ1WFx2bQblhrg8i8R7hcLjU6bRNrw02YF3KWmba5RmJ1Pgj+8fCELIOWcdiTUS0lPM1NEJJHAVxsG2q4KncQw4MLuZ/XMn9rIII0yn4X7DKPPhZfO7m33d1rkOOWkKPHCcgEDUhgrGxO/9Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780491674; c=relaxed/simple; bh=bDNIkiVVO2nsF1Cs9if6qfNGi8eoMLFX2wCBGBvphOI=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=R31BRgpCoB2DV9O5x9rjPiRM2M6sFYbFxhYbuDYdeVuT7TwFVl6RRfO7J8yhMiN/mF3jjhKinHXVZBZEhuzQK8M5opR5c1HWhTlPHOEuvnEVMbBZMTpGKEFARbRrNa+Avdd+zxMqFNhsVP9Ifai4qpg0d3L9ks18jM4YF+Pu9ww= 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=LpqFd78l; arc=none smtp.client-ip=220.197.31.3 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="LpqFd78l" 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=YB iIKzWvi3JYD/VDRS7JeTKo3NMwUfsiL94eG8g6yu8=; b=LpqFd78lxpXqveDq+J zfQCFO6YtMg+11yytRvQQ69ldn56bkwJ3YUQZcDcf7/VOHo5pO5yaBkFC+K3ZApV qbFf2Vdwp8qnaaPlBmRWZmsTmvu2h+6lHJ8Vc8JXwS5zRfLFpeJFHB5dhJXE+rRz arGYzzfWdDa84BMypSXEcaNvU= Received: from zhaoxin-MS-7E12.. (unknown []) by gzga-smtp-mtada-g0-1 (Coremail) with SMTP id _____wAn7Zs8JSBqNAysBA--.36123S2; Wed, 03 Jun 2026 20:59:41 +0800 (CST) From: Xin Zhao To: 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, vschneid@redhat.com, kprateek.nayak@amd.com Cc: linux-kernel@vger.kernel.org, Xin Zhao Subject: [PATCH] sched/fair: Don't trigger active lb if src_rq->curr is CFS and not on_rq Date: Wed, 3 Jun 2026 20:59:38 +0800 Message-Id: <20260603125938.1938115-1-jackzxcui1989@163.com> X-Mailer: git-send-email 2.34.1 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-CM-TRANSID: _____wAn7Zs8JSBqNAysBA--.36123S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxGw43tryDWrykGF1Duw1kuFg_yoWrXrWfpF WqgF4UWr4kJa4rJ3yvkay8ZFy7Xr9rXayUXas8tF1Syr45W3Wq9w1Sgay3CFyUuwsYkF1a ywnrK3yUKw4UKaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zEF1v7UUUUU= X-CM-SenderInfo: pmdfy650fxxiqzyzqiywtou0bp/xtbCwB36BWogJT3U9AAA3Q Content-Type: text/plain; charset="utf-8" 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 =3D=3D &fair_sched_class && !busiest->curr->on_rq succ: the active balance success cases that match cpumask_......->on_rq fail: the active balance 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 We add the situation not to perform active balancing. For cases where src_rq->curr is a non-CFS task, we retain the affinity check for dst_rq because such task is likely to wake-up or woken-by src_rq CFS task which has similar affinity characteristics to migrate. We attempted to execute list_move_tail for the curr CFS task on src_rq before unlocking src_rq, but testing showed no improvement in the traversal count of cfs_tasks in detach_one_task(). Additionally, in sched_balance_rq(), we unconditionally reset the balance_interval to min_interval. The difference is that original logic does not reset the balance_interval when dst_cpu softirq handler is preempted while src_cpu successfully run the just-dispatched active balancing, during the gaps between two need_active_balance() checks. It seems that we haven't observed any substantial benefits from reducing the opportunities for balance under such fluctuating conditions. Signed-off-by: Xin Zhao --- kernel/sched/fair.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index b5819c489..cba6dc6da 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -13423,7 +13423,9 @@ static int sched_balance_rq(int this_cpu, struct rq= *this_rq, * if the curr task on busiest CPU can't be * moved to this_cpu: */ - if (!cpumask_test_cpu(this_cpu, busiest->curr->cpus_ptr)) { + if (!cpumask_test_cpu(this_cpu, busiest->curr->cpus_ptr) || + (busiest->curr->sched_class =3D=3D &fair_sched_class && + !busiest->curr->on_rq)) { raw_spin_rq_unlock_irqrestore(busiest, flags); goto out_one_pinned; } @@ -13455,10 +13457,8 @@ static int sched_balance_rq(int this_cpu, struct r= q *this_rq, sd->nr_balance_failed =3D 0; } =20 - if (likely(!active_balance) || need_active_balance(&env)) { - /* We were unbalanced, so reset the balancing interval */ - sd->balance_interval =3D sd->min_interval; - } + /* We were unbalanced, so reset the balancing interval */ + sd->balance_interval =3D sd->min_interval; =20 goto out; =20 --=20 2.34.1