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 B7712277818 for ; Fri, 23 Jan 2026 06:07:04 +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=1769148428; cv=none; b=CntFxpXQuhDRDpkxdExfkYh/fMDpK4Vhn1N3ZjzRPII8mFzR+053vfuJfBdc3joVF7V7AwUmO2VvwDiXJHmEnGxfQBajkcr7rOJisQ7ylN/JufVufo+PsYJLMe47vEEjgu4F88yjVD+URUr7B+9JW8Dbe9s3nENxm3ZAAWYbp7k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769148428; c=relaxed/simple; bh=foZgyd90aO9jiyVvnPkSdLctQJ7RDAaT4OiKgHWH5fA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=EkIaDynhmhAu7B8O0+hx9bZP7yi+vcwZUQEXZgGJXjLwloGIGpiziP79JYYbFKlw+5aOqGyhNh/dopSo3pVG+BVoMEnai8Qd43TVDd9wP3DJU6e4rOKWViCvSF8JjC/L8gIH6zRsWYoNwxkRHcYxXRVNTuGx8yNJZB5VacK+cf0= 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=CNPGaLqi; 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="CNPGaLqi" Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 60N3HTet006841; Fri, 23 Jan 2026 06:06:38 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=lvvG6g 6DvL0zcuP7QO1htiXK2fnyCcong/MC20YcAtI=; b=CNPGaLqizlvTt3/YLhKL5X 5q1WV2wS0mZdB2EPxUrRvfqxG7JV+fJiPAKOsXVMRFTc7j/UZwbuiVuMylvGYcPs MbuBUjRpvuJl/MGYCKNIznLhvIatl1i+QbZFLZnDL3hiItXKxLhy1NuxgE6uw58C CpMMa9LGKRaU45C26ZLQNC7GOqPo/h83PR9w50cZ2AK0Ib/m1A2caJz05nPXAVbU Oep+yY1yjff7MA1kiK8eQUEP7WnYSEFgsa1dkD3o9DmiSC2vxHcNmpFUnc3Nduvb RE254JhJcZSMh8aSVuTYTugbEN0qI2DrBKkt5s09rHlk17LNN+eUsgOzNPTblvyw == Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4br23se9qw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jan 2026 06:06:38 +0000 (GMT) Received: from m0353729.ppops.net (m0353729.ppops.net [127.0.0.1]) by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 60N60iMm027417; Fri, 23 Jan 2026 06:06:38 GMT Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4br23se9qu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jan 2026 06:06:38 +0000 (GMT) Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 60N4RRU1001441; Fri, 23 Jan 2026 06:06:37 GMT Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 4brpyk77ee-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jan 2026 06:06:36 +0000 Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 60N66Z3r51446166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 23 Jan 2026 06:06:35 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 44F8820043; Fri, 23 Jan 2026 06:06:35 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6973020040; Fri, 23 Jan 2026 06:06:32 +0000 (GMT) Received: from [9.39.20.150] (unknown [9.39.20.150]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTP; Fri, 23 Jan 2026 06:06:32 +0000 (GMT) Message-ID: <3017c721-e4cc-4c6a-b2fc-51e2c8e01711@linux.ibm.com> Date: Fri, 23 Jan 2026 11:36:31 +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 v3 8/8] sched/fair: Simplify SIS_UTIL handling in select_idle_cpu() To: K Prateek Nayak Cc: Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Chen Yu , "Gautham R. Shenoy" , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , linux-kernel@vger.kernel.org References: <20260120113246.27987-1-kprateek.nayak@amd.com> <20260120113246.27987-9-kprateek.nayak@amd.com> Content-Language: en-US From: Shrikanth Hegde In-Reply-To: <20260120113246.27987-9-kprateek.nayak@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: BM4GaDSQVHELbdJP6URp8b8OAuAZ_XwS X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTIzMDA0MSBTYWx0ZWRfX7HmssW3fwhU0 RdgYRPlIAtzBDJK4n0/uNrpMlUxKUPbYtmJc2k6Tqp5TeO04hlMfV56KtZLy2NSHtu2WBSreVmH YAManfyyiltc3qpxWLsUjUHKpYN/qYd7DOVAFsy934dNCNs/ObjM9K0hZobgDzMXGyqwpmIerSK DD7AoqpqEu65oo8pfPzlEBo47i9nzV19OA3DGO+kSHWhxGdHAmKSJi6n7vtvWLpkH73jWKDFQko dScOeIV9ZPdFltbzvHIUEDUeLoScd/+MxfKorajdFL9wLHv/mSEav8Y8yrCttgB3a/krsx/FEir LXS1FfzW1u1lGSv8AmLF4tjKVTp5Fu6p671ACH3KIytyPdQzvRf9VmJGROcUGxLFgvoK+05lLkn UIsgQpRz95gLM58hodZ2uH48h0ERY7S+B+TeynMbHw6RR0ffp7qiFJELpr2nBVv+XUqLmZ+PJJt zB3daVs+5TPcxPZd8kw== X-Authority-Analysis: v=2.4 cv=J9SnLQnS c=1 sm=1 tr=0 ts=69730fee cx=c_pps a=AfN7/Ok6k8XGzOShvHwTGQ==:117 a=AfN7/Ok6k8XGzOShvHwTGQ==:17 a=IkcTkHD0fZMA:10 a=vUbySO9Y5rIA:10 a=VkNPw1HP01LnGYTKEx00:22 a=zd2uoN0lAAAA:8 a=VnNF1IyMAAAA:8 a=QUxie0fuviLoTocKV7oA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-ORIG-GUID: FuAIRA9C-ds-ZqT6G-iRE3AsiTKAPU3Q X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.20,FMLib:17.12.100.49 definitions=2026-01-22_06,2026-01-22_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 impostorscore=0 adultscore=0 suspectscore=0 spamscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1015 bulkscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2601150000 definitions=main-2601230041 On 1/20/26 5:02 PM, K Prateek Nayak wrote: > Use the "sd_llc" passed to select_idle_cpu() to obtain the > "sd_llc_shared" instead of dereferencing the per-CPU variable. > > Since "sd->shared" is always reclaimed at the same time as "sd" via > call_rcu() and update_top_cache_domain() always ensures a valid > "sd->shared" assignment when "sd_llc" is present, "sd_llc->shared" can > always be dereferenced without needing an additional check. > > While at it move the cpumask_and() operation after the SIS_UTIL bailout > check to avoid unnecessarily computing the cpumask. > > Signed-off-by: K Prateek Nayak > --- > Changelog rfc v2..v3: > > o No changes. to the diff. Added more details on directly dereferencing > "sd->shared" without a NULL check in the commit message. > --- > kernel/sched/fair.c | 19 ++++++++----------- > 1 file changed, 8 insertions(+), 11 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index c308c0700a7f..b4ae9444d32f 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -7629,21 +7629,18 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, bool > { > struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_rq_mask); > int i, cpu, idle_cpu = -1, nr = INT_MAX; > - struct sched_domain_shared *sd_share; > - > - cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr); > > if (sched_feat(SIS_UTIL)) { > - sd_share = rcu_dereference_all(per_cpu(sd_llc_shared, target)); > - if (sd_share) { > - /* because !--nr is the condition to stop scan */ > - nr = READ_ONCE(sd_share->nr_idle_scan) + 1; > - /* overloaded LLC is unlikely to have idle cpu/core */ > - if (nr == 1) > - return -1; > - } > + /* because !--nr is the condition to stop scan */ > + nr = READ_ONCE(sd->shared->nr_idle_scan) + 1; > + /* overloaded LLC is unlikely to have idle cpu/core */ > + if (nr == 1) > + return -1; > } I stared at sd->shared->nr_idle_scan for a while to see why it is safe even when lets say there is no LLC domain. It is because it is sd_llc here. Not any other domains. and there is sd_llc check before calling select_idle_cpu. So maybe add a comment here, saying null check for sd_llc is already there and that's why it is safe to call it directly. > > + if (!cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr)) > + return -1; > + > if (static_branch_unlikely(&sched_cluster_active)) { > struct sched_group *sg = sd->groups; > While reading this series, this reminded me we had discussed about unifying sd_llc->shared and sd_llc_shared thing into one (in v1 or v2). is that dropped or you plan to fix it after this series? Other than minor comments and nits series looks good to me. So, for the series. Reviewed-by: Shrikanth Hegde