From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 08C7D2DFA54 for ; Tue, 25 Nov 2025 07:09:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764054574; cv=none; b=Yp+gddwxfxN0smwtMR1H78fWlmgdu9DO+WkAEmUCy6uWxdAS5zctn/d3LOBt6TXLKXauf2Br4xzO8/m+/+W3EzCtdLqz6ZUIcTR5RZ2L4n/bO3l/lG9nk/GCmCZhc6lzlie38umgQvLTOIWEPWG8usiiksOsiuss5toHXJHVqJk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764054574; c=relaxed/simple; bh=1URbNYc6/+GW7/ckmnY1vlk2Cv99agmmbeBGGdwAmk4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=iUBkNLEaNgm85ZWWZstSEl+yQW68Ke8Ezlx6UClo7DFSD8pViiQ/UgS/nokHGl+hIkbz3vHDqWLmfQ0RK1omEbkCBIcaeGshL+DKJJrYALIJusVBQrH+uhhZhht5YGb3kT+wbSubUoqsM8Ml7rePy4edULi5+JrOupXcgVxHbU4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=s1YHrXLL; arc=none smtp.client-ip=148.163.156.1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="s1YHrXLL" Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5AP3Wal1030902; Tue, 25 Nov 2025 07:08:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=DslzMk ez0X19QMcjepWHcUTl0yY+XPDroEQoPU0+5zg=; b=s1YHrXLL3mVWrcz/3uFI8O jy22AgU8gKebtOzY9EVAFx3wkZrh7ykM54IwVyt1htu3pZSfICiTd4IYtGg7RaZp YaR0ZjdfL1DYcb98DCIS9T3u53KUPFb34tYp8Hk43dvALr/qG77TmRHTSj0trU0R b3X9yByTbxGqYcd2LJI16qSMR+RLAhPqPOPwId+flgrTBjab+jZ6paPYrWSWVnor BD3TDax4Mqa4oHOCtYFq0S6XArSh7HRHTrWiYJ+09jaWs1N6wcorWMjMiRMh7lpy hgliQTseu58VsVkoWLKY0HfBOOjd37zf4KpbJH2T024L8Vgrt3w0R2w3mb/HGvKw == Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4ak4phuyp2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Nov 2025 07:08:33 +0000 (GMT) Received: from m0360083.ppops.net (m0360083.ppops.net [127.0.0.1]) by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 5AP70N6J007922; Tue, 25 Nov 2025 07:08:32 GMT Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4ak4phuynu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Nov 2025 07:08:32 +0000 (GMT) Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 5AP5oW44000835; Tue, 25 Nov 2025 07:08:31 GMT Received: from smtprelay02.dal12v.mail.ibm.com ([172.16.1.4]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4akqvxtb83-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Nov 2025 07:08:31 +0000 Received: from smtpav04.wdc07v.mail.ibm.com (smtpav04.wdc07v.mail.ibm.com [10.39.53.231]) by smtprelay02.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 5AP78Usb45941078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Nov 2025 07:08:30 GMT Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3701B58050; Tue, 25 Nov 2025 07:08:30 +0000 (GMT) Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 82A2F58045; Tue, 25 Nov 2025 07:08:23 +0000 (GMT) Received: from [9.43.26.70] (unknown [9.43.26.70]) by smtpav04.wdc07v.mail.ibm.com (Postfix) with ESMTP; Tue, 25 Nov 2025 07:08:23 +0000 (GMT) Message-ID: Date: Tue, 25 Nov 2025 12:38:21 +0530 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] sched: update the rq->avg_idle when a task is moved to an idle CPU To: Huang Shijie Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, patches@amperecomputing.com, cl@linux.com, Shubhang@os.amperecomputing.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, linux-kernel@vger.kernel.org, vschneid@redhat.com, Madadi Vineeth Reddy References: <20251124023745.259267-1-shijie@os.amperecomputing.com> Content-Language: en-US From: Madadi Vineeth Reddy In-Reply-To: <20251124023745.259267-1-shijie@os.amperecomputing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMTIyMDAxNiBTYWx0ZWRfX8y200ib2pzfy RXJG5qQu2PhEzXglV+Tm6VXpy8M8yst8+ojmcz/EReh1ijRjlkv5dZc1aVwY98XanrDrpiJ1mWq FF7Vuckfb7MzgR4h+SMH5uHkwp7bAiqp4NMhdgx9MHTiTME/D2A87zA9wEyCl1uyNybIX+FWrPP GE/cAMpEAJj2dzcM3CpG1X5JFlizxRvqwtXrGVsvwX4Co+2rzjdc5dZOTeSRiD9BlrD78jNsfPm JxokaZ9XSd00XZOpLYcm5aUophYrrtogh5fS+Il4pM5VhqJGUwBL9dArBSaOWso3AcwUULy0t9q b6fgv9LFjEc45e/517nKosS5H9Ymbg+QpLcZytY8dRz+2p3CelyZYxh7fDXivdKmEckKiiLtNXE /TSB3aerSDMbaBB2ZLSKq8iccnMhNQ== X-Proofpoint-ORIG-GUID: JDhxkaXfaP8Zhs6eyWMgi7-lf_xNaX8L X-Authority-Analysis: v=2.4 cv=CcYFJbrl c=1 sm=1 tr=0 ts=692555f1 cx=c_pps a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17 a=xhGV2N9cJkzbW6Lu:21 a=IkcTkHD0fZMA:10 a=6UeiqGixMTsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=vzhER2c_AAAA:8 a=5G6Y1Lloyj3TcB43ei0A:9 a=QEXdDO2ut3YA:10 a=0YTRHmU2iG2pZC6F1fw2:22 X-Proofpoint-GUID: jw-pHcBlURCbVi31nd_XTjthJxMW_6dN X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2025-11-25_01,2025-11-24_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 suspectscore=0 clxscore=1011 adultscore=0 spamscore=0 phishscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2510240000 definitions=main-2511220016 Hi Huang, On 24/11/25 08:07, Huang Shijie wrote: > In the newidle balance, the rq->idle_stamp may set to a non-zero value > if it cannot pull any task. > > In the wakeup, it will detect the rq->idle_stamp, and updates > the rq->avg_idle, then ends the CPU idle status by setting rq->idle_stamp > to zero. > > Besides the wakeup, current code does not end the CPU idle status > when a task is moved to the idle CPU, such as fork/clone, execve, > or other cases. > > This patch introduces a helper: update_rq_avg_idle(). > And update the rq->avg_idle when a task is moved to an idle CPU at: > -- wakeup > -- fork/clone > -- execve > -- other cases > > Signed-off-by: Huang Shijie > --- > kernel/sched/core.c | 29 ++++++++++++++++++----------- > 1 file changed, 18 insertions(+), 11 deletions(-) > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 9f10cfbdc228..732c6f708afc 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -2412,6 +2412,21 @@ static inline bool is_cpu_allowed(struct task_struct *p, int cpu) > return cpu_online(cpu); > } > > +static void update_rq_avg_idle(struct rq *rq) > +{ > + if (rq->idle_stamp) { > + u64 delta = rq_clock(rq) - rq->idle_stamp; > + u64 max = 2*rq->max_idle_balance_cost; > + > + update_avg(&rq->avg_idle, delta); > + > + if (rq->avg_idle > max) > + rq->avg_idle = max; > + > + rq->idle_stamp = 0; > + } > +} > + > /* > * This is how migration works: > * > @@ -2446,6 +2461,7 @@ static struct rq *move_queued_task(struct rq *rq, struct rq_flags *rf, > WARN_ON_ONCE(task_cpu(p) != new_cpu); > activate_task(rq, p, 0); > wakeup_preempt(rq, p, 0); > + update_rq_avg_idle(rq); > > return rq; > } > @@ -3646,17 +3662,7 @@ ttwu_do_activate(struct rq *rq, struct task_struct *p, int wake_flags, > rq_repin_lock(rq, rf); > } > > - if (rq->idle_stamp) { > - u64 delta = rq_clock(rq) - rq->idle_stamp; > - u64 max = 2*rq->max_idle_balance_cost; > - > - update_avg(&rq->avg_idle, delta); > - > - if (rq->avg_idle > max) > - rq->avg_idle = max; > - > - rq->idle_stamp = 0; > - } > + update_rq_avg_idle(rq); > } > > /* > @@ -4773,6 +4779,7 @@ void wake_up_new_task(struct task_struct *p) > p->sched_class->task_woken(rq, p); > rq_repin_lock(rq, &rf); > } > + update_rq_avg_idle(rq); > task_rq_unlock(rq, p, &rf); > } > I traced the activate_task() call paths and found that load balancing migrations through attach_task() in kernel/sched/fair.c may not be covered. activate_task <- attach_task <- attach_tasks <- sched_balance_rq activate_task <- attach_task <- attach_one_task <- active_load_balance_cpu_stop These paths are called in periodic load balancing and when tasks are pulled towards an idle CPU via attach_task(), it doesn't update rq->avg_idle or clear idle_stamp. Should attach_task() in kernel/sched/fair.c also call update_rq_avg_idle() after activation? Also, can update_rq_avg_idle() be placed inside activate_task() to avoid all these? Thanks, Vineeth