From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (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 2BFD91D5146 for ; Sun, 14 Jun 2026 04:18:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781410687; cv=none; b=mz1Lwe3re/8QYQZF3SQC4hU0hRerKGi14I1E5QPcPyeX/5T1GAYkAAQCgeG3nKz9qIS0WbuvBNZ1Ry6Pyf0979taYC+p9LsqBEs4MVOHmAYrBzFWUjyrm2HBnD2xpgMtn+a8SRk0Q9yzGtXOXVLQF9HbE/E/hWuSo2lWDQgP570= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781410687; c=relaxed/simple; bh=gt8ScYCQ55Aj3aK2JOjMd3BbxQ2u3zagrMSK6kAhe5w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=DHYVaoQcAqeP0giLqiEPxuDk9VIChVJdWPvtykBCEkDhBPhldnWkESCUc871GIlu28BoJsdmjt62RXaaoVx3D4gjkP5iB/tEr0WlFoyrOzbmtJ5DtSePqh1ua4u6lxwvjxuer8UlErmfkqMpwXe+NJF4/FtWtUQWJZiTAWw7cjc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=Oi8WyTe3; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=d2O1suY6; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="Oi8WyTe3"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="d2O1suY6" Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 65E48uXS124729 for ; Sun, 14 Jun 2026 04:18:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= 65IM1484zcpc6ZfYvPuXSgXusoQtZhkFT8M2tbDEiKk=; b=Oi8WyTe3b1WewKMy 5g6Kk6rA9xHZ3IGOISkkmgaYnDa8Gid4GkzLZk60PmGoFMLlJKoX3vLC2b1se1Mj zPhItJ+NdPVo8xavGJhdD5dn36JxLhw6ZqNmu3f1vXXPMUXGNxxN+GXlEoCvwcI9 d+DEHKMbOqPKBil8CUMw/9YsylIzMfq8axslGnxz6WAP3dmURqxKze8bJF8rW2P1 SEIVnM59svfW9h4X5jibtMKDRe2LHDs+xm+pXEW131S1Jeg0/9GhNVeRRfbv6Lyq rBtkm+UvcsUdjixFHR/8kwLPDl+0LkcpDzNgyz13LH0MZBk8jDJuAH8X5SFey6/u 2B/ALA== Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ery9faqs2-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 14 Jun 2026 04:18:05 +0000 (GMT) Received: by mail-pj1-f70.google.com with SMTP id 98e67ed59e1d1-37723fb0941so599249a91.0 for ; Sat, 13 Jun 2026 21:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1781410685; x=1782015485; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=65IM1484zcpc6ZfYvPuXSgXusoQtZhkFT8M2tbDEiKk=; b=d2O1suY6OnQk2eAkCZcKflY7csnkOxZq/js0YuPnC9Ql6OHbz8YN77Dncx2LGnuh10 pDN6E+KFH2XJpWAl2LAs2RTKIZ/tUIBoqG1cD5bvKgBVf40bIj2kbXZOP7Cmb8cDAIu2 UXi3iOioIve46cjdEapmy1huaLLjYId3kbXL1VNIf1XjP7+gYbKrcmwGuYPGcFKD2DW1 Rzpb/ql2SFIPyGvBMQPhGrul6ZNW++M9ws05I5dOP7WutUIzdZ3Iqv/7dCsmh0VnT/E7 Dqjli6wq6AHTQ5+j32roIaFWrAmwkDtlj9GgNTdOO+YGdakkuiqiTsC67tzWQ6+SWl/q j0XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781410685; x=1782015485; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=65IM1484zcpc6ZfYvPuXSgXusoQtZhkFT8M2tbDEiKk=; b=JxDCjt7MjD8MSszviV/XCHEVEwboSK5vADNQZNtnwJLgFo5HhQfMA28BmqZYf3cTGS 3rYcVrWSpbjTIjDfXObkAEQBzsLUfyC2q3hrNbAZRG8M3GThenAUpPQUSaD+pH+ejb74 bP2kJB+922sx+nmRv8iCgNxguvIuXxm4N3FjVVc5Y3eIYBJUXnwMTZfxbV/lDRJ0rXaj yB15mJ4dtTgWHCDr6d0R5VhjqyKr1ClPyTHMy1RqmClYa+YdGUKwdIJyX8jFvcP9WsI0 niwghxHunZPbmOqqLD3czBCacwzGeU9PIdXyGbw82F9Pw80fktpzs3lejZyq0NbbwI0m fA6g== X-Gm-Message-State: AOJu0Yziazzht1TOOuzB737r4/CGv3fTuP3P1bfhX7+Wnn7oO53nJNk+ Yyx5IGI3axy/BzUDj57h2gFL0Z/DiJ/cgOiNvLTArK6V0r5AK8Bvq6lZXesMp0odvdFymslaV79 z6qD5RB9gdhtCGO4N6xtk96F4C4wWRXVCldknQsNl1KyIgtyCsYEgJLSGaO9rttz+ePtdutHFOX w= X-Gm-Gg: Acq92OFbsTw/GIhnGPiwreaa18IvkljnAauw8KRbkoOK4bGaPVdRhwtWBXt7dwmUCAB 98vJJ/B411yOMdrMfJzmTsJx19GI5lpTc79dRrOgaW6i3Xm3MiYwYEFWnk7r2+Cn7RDg9idY0qk RZMVXoK4LZRrF1jpwN2Eb8iNnNCLcql85har+X9z4hwFmyDQvfxJcYI6o1+aIIcc7ROCZRu+4EO megYFfXkNEfoUjN7ffwd3S4FhL9SdZWeGwfUfHATjm8gLHpmtGY3XuG63HZB91BYDwD2H1Gm4X4 5tjosy6ItMXXalDtnjPLvKZiKNRpx2OdAcUo91fwZCiiK/k3pK8yKGQKpQ2On/3oFUa3yQ6yYok pzv0fSyvS12IORWPRQxU2alM251doa3wQS2go4PCobKN0Lg== X-Received: by 2002:a17:90b:2ecd:b0:366:2b56:3ec2 with SMTP id 98e67ed59e1d1-37a0155ffd6mr4600974a91.1.1781410684564; Sat, 13 Jun 2026 21:18:04 -0700 (PDT) X-Received: by 2002:a17:90b:2ecd:b0:366:2b56:3ec2 with SMTP id 98e67ed59e1d1-37a0155ffd6mr4600963a91.1.1781410684042; Sat, 13 Jun 2026 21:18:04 -0700 (PDT) Received: from [10.239.132.150] ([114.94.8.21]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-37a262adbe3sm7747110a91.13.2026.06.13.21.18.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Jun 2026 21:18:03 -0700 (PDT) Message-ID: Date: Sun, 14 Jun 2026 12:17:37 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] sched/fair: Don't trigger active lb if src_rq->curr is CFS and not on_rq To: Xin Zhao , 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 Cc: linux-kernel@vger.kernel.org References: <20260613073228.1951105-1-jackzxcui1989@163.com> From: "Aiqun(Maria) Yu" Content-Language: en-US In-Reply-To: <20260613073228.1951105-1-jackzxcui1989@163.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjE0MDAzOCBTYWx0ZWRfX1OU6w6A+RWU6 gyiU5ofYDQtV2adTdkmSDaMCyGBDukE427V3Ox3FMbYzhcWnY1iyi0sqDRu1WYEtv0VnTDydY3W O17GNjiSsS1bfgWYdqkmZHptbGD4aJFGWfFw7mEU0f5HsCPOwcN9JTMj7mX61sLqRY7muzMxGUR 6dLIvR7gGVTL9Kyt8vMm/3vJnon67hiDdwr/MIOAKvDTHDFKEmXgSmVIDGiesOt+0QSIMrm/pzU gnmp3PDya8G7bXDKX+035dIcWmibMyWyWwP6MdmZs4xGKTse1++CI9JVqEqtBv2aLbyxn4KU5Bj QZezM1GWqO66ReqOdSqYIVa6uI2WnsXntT54l6xOWC4nc55lWrbojVV5154FnHjkKRLfs+ysLtR PP8kVLVelG2/H/KYvvjdn3lW5VX8YFHqTq7JMlsAnep4JoCesgS4mJm9bvC+yrkilt+icTSbSCv WbbkrFY6+rk1e0hfJ8A== X-Proofpoint-Spam-Info: AW1haW4tMjYwNjE0MDAzOCBTYWx0ZWRfX8i8OQ3TTPe5J iIN22dbtejGalJbOoAXZfC/Yly9a5iuuO84D44I7zkrWdwWcEHKTT87Q/IrCi8vuEgERRY0KhrY S5QHRgSHJNszrTv2UCMZ1rMWDBZ3s5E= X-Proofpoint-GUID: YlHxM9Ndbo74EV7WNcxvzv9CKnAAPmyR X-Proofpoint-ORIG-GUID: YlHxM9Ndbo74EV7WNcxvzv9CKnAAPmyR X-Authority-Analysis: v=2.4 cv=ULvt2ify c=1 sm=1 tr=0 ts=6a2e2b7d cx=c_pps a=0uOsjrqzRL749jD1oC5vDA==:117 a=Uz3yg00KUFJ2y2WijEJ4bw==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=eoimf2acIAo5FJnRuUoq:22 a=VwQbUJbxAAAA:8 a=Byx-y9mGAAAA:8 a=JhnwQKABfIVfTXTZlv8A:9 a=QEXdDO2ut3YA:10 a=mQ_c8vxmzFEMiUWkPHU9:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-14_01,2026-06-12_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 clxscore=1015 phishscore=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 malwarescore=0 adultscore=0 impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606040000 definitions=main-2606140038 On 6/13/2026 3:32 PM, Xin Zhao wrote: > 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 What's the probability that curr->on_rq is 1 throughout the entire check? > > 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. This situation occurs quite frequently because: > 1. Periodic load balancing across CPUs often happens in close succession, > leading to collisions in the rq lock during sched_balance_rq(). > 2. 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. It is possible that curr->on_rq is seen as 0 and don't need to do active balance. While my concern is the overhead of check "curr->on_rq" every time to the possibility of curr->on_rq should be considered as well. > > 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. > > 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. So simplify This is not that clear to me. And could you pls help to have more data and example to have more details? Maybe it can be separate with different patch? > the need_active_balance() checks logic. > > Signed-off-by: Xin Zhao > --- > > 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. > > v1: > - Link to v1: https://lore.kernel.org/all/20260603125938.1938115-1-jackzxcui1989@163.com/ > --- > 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 == &fair_sched_class && > + !busiest->curr->on_rq)) { if busiest->curr->sched_class != &fair_sched_class, do we really need to do active balance here? Also maybe unlikely(!busiest->curr->on_rq) instead. > raw_spin_rq_unlock_irqrestore(busiest, flags); > goto out_one_pinned; > } > @@ -13455,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)) { If the active_balance already triggered, why still need reset balancing interval? > - /* 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; > -- Thx and BRs, Aiqun(Maria) Yu