From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.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 74019242D70 for ; Fri, 23 Jan 2026 07:14:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.158.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769152498; cv=none; b=HE2+HUI1gaxTTz62OoK8NRBZoRHDkAEIeUb56hK7djxCK6/de1HhPm40YBJwGuPc8X4N3+5BQntQVEBQhPIQnX5DDz9MOANtT5jwfGWKG5crGtIoTG9mEeSKgRlcI7O4H7hAC/WmUVI4xC6ntyBl2mB3ZNBbF19yVatgJH9OVNY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769152498; c=relaxed/simple; bh=wltaEQqe6YLWn3urZeGLLWAORtC2+bJ3smJyZwohOog=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nSR27C9J1jNnKzYwtUDeZX50/o5GssTbQwzQAtNux1ZczE6EnTEv//2F8Jn5kLdG9dJzgdPTpDdsnrOel76U82V7fWaXcQrsiGco6vQli0v2Dh/hC0NE4k8T3j5RuYmUVRMyKGWLgSrcgP0EO7nNJV17LYG/soQpAuxtIh+e6EE= 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=Rciwm8K5; arc=none smtp.client-ip=148.163.158.5 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="Rciwm8K5" Received: from pps.filterd (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 60N72EEd005920; Fri, 23 Jan 2026 07:14:41 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=ATG2Sn S/r7F8w/1bEGekG0Pdesyqcwf5+Cz1YMTI1rM=; b=Rciwm8K5Hv6yzllYZSOVFy LTdIylN+tgU59f5a43aq/0tbqWpwGQP59cuW4PF8Bcox57FCHP+z8oREgwDFlD+O T7Bb5AQTDRngBG7rZqYm4UD1bqLdpSd48Gt4WaN9DOumLDe9ke0097COBJ28BWxj viUItsomOzSO2IAdTmWCbDh3jMVCYb0GbMKjBRGtLKrtgCO8DFfiNc/2reCzI9KZ EE6bjW924rblQkPr3XrCllmKmzF8G6RcKnoQpn4VAgo6hp2mBwjYCBDENLLFfvnf Q/h82R2Z2F4aDucmAusEfmm+Ss7774Y9pivb3TAwMVZIzoeyOPsx0nF7uGsSKEfw == Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4bus1ptw2j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jan 2026 07:14:41 +0000 (GMT) Received: from m0353725.ppops.net (m0353725.ppops.net [127.0.0.1]) by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 60N75I78012578; Fri, 23 Jan 2026 07:14:40 GMT Received: from ppma21.wdc07v.mail.ibm.com (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4bus1ptw2b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jan 2026 07:14:40 +0000 (GMT) Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1]) by ppma21.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 60N78063027274; Fri, 23 Jan 2026 07:14:40 GMT Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4brnrnfput-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jan 2026 07:14:39 +0000 Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 60N7EbfP12255644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 23 Jan 2026 07:14:38 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D51F12005A; Fri, 23 Jan 2026 07:14:37 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4B54E20043; Fri, 23 Jan 2026 07:14:35 +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 07:14:35 +0000 (GMT) Message-ID: <3cf686fe-7068-440f-84c6-414db71b9c36@linux.ibm.com> Date: Fri, 23 Jan 2026 12:44:34 +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> <3017c721-e4cc-4c6a-b2fc-51e2c8e01711@linux.ibm.com> <00a09fd8-6ed7-4ebf-a146-d054e98cc45b@amd.com> Content-Language: en-US From: Shrikanth Hegde In-Reply-To: <00a09fd8-6ed7-4ebf-a146-d054e98cc45b@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: Wph-xE1GmZAkvYoHzfsg9UYxqGURykRU X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTIzMDA1MCBTYWx0ZWRfX8YJIXgyr++lh 8eb3zc8VFSWkzb6wR974l1fx+7nVYwzOXFEQt66u3qYU6BpbcHACKhM4ZhwRfIV7kh80Y5jwsoG fek/mr3dbf3WOcuhI7ApOWJOuCtXPfcMl4Z6rsEcnq7n9snqGrHT5SEJUBSxoA2p0VzKXI1tmi6 c4ggMaiqxIc+Dty+8RCE2Qu7egCxonnADLl/2m3JMui00dhiT5vIQZkpLePfv/AgewpySuTxcCD SdfVKij4yIoHk6xF+LVndRKU/BHxthxH+xS963DCtFTH4CYj2xvFjO7CshGvjWPqJ+M0qgjPJ9Y ehrCQXL+ftqXKTtz5k28qByH3zgq7POAvkCpRc34yyiT5PR8IS1yXCOOMl0zbQlKXlAH42h4Ttp aTQuFqOB4iZaVOMxkTw769xPJBssA+m96Pg621iou/wcC9PJBxXnqhBY8IH4qBkzhQWNyIvr6Q0 JTRQipDlarXAUBWt50w== X-Proofpoint-GUID: YkY-Ytyp6XjIRn3onItY1Qae346j8VhT X-Authority-Analysis: v=2.4 cv=GY8aXAXL c=1 sm=1 tr=0 ts=69731fe1 cx=c_pps a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17 a=IkcTkHD0fZMA:10 a=vUbySO9Y5rIA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VnNF1IyMAAAA:8 a=GJlSxo7m7AjQRUkNu-8A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 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 suspectscore=0 impostorscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 malwarescore=0 priorityscore=1501 bulkscore=0 adultscore=0 clxscore=1015 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2601150000 definitions=main-2601230050 On 1/23/26 11:57 AM, K Prateek Nayak wrote: > Hello Shrikanth, > > On 1/23/2026 11:36 AM, Shrikanth Hegde wrote: >>> +        /* 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. > > Ack! We come here with a valid "sd_llc" from select_idle_sibling() > and "sd" and "sd->shared" are freed at the same time via call_rcu() when > the last reference is dropped so having a reference to "sd" guarantees > "sd->shared" is not freed and the topology bits will ensure > "sd_llc->shared" is always present (or it screams and we crash here). > >> >> 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? > > Must have slipped out of my mind! I believe the only other user of > "sd_llc_shared" directly would then be nohz_balancer_kick() and > {test,set}_idle_cores(). > > Out of those, I would only consider set_idle_core() from wakeup to > be a fast-path but we'll already have a "sd_llc" reference there > so we should be able to flip the idle_cores indicator without > needing an extra dereference. > > We can only keep per-CPU "sd_llc" and remove "sd_llc_shared". I > hope that is what you were suggesting. Otherwise please let me > know if I misinterpreted the question. > you got it right. keep sd_llc only. >> >> >> Other than minor comments and nits series looks good to me. >> So, for the series. >> >> Reviewed-by: Shrikanth Hegde > > Thank you for reviewing the series. >