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 3D69A1E1024 for ; Fri, 20 Mar 2026 14:12:59 +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=1774015980; cv=none; b=Lm0/euIlLQ1IWSFkoymlTkvLdSqDXO+U01aMIgZAp1XVdFyn94fdRUMMet0BqqPUoBACLOKbm661ycsmgbrZFqjphama0LaiG02bt21WVnTM4VAiPaAAyIzSGdFuc3USdCZqhAXBka72CbYsCiFgI44ioqSJm09diiAPr0shqqs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774015980; c=relaxed/simple; bh=ltPH+tBUFt/LQ8p0KOGLb9A6OQ1gPjoAlrsiejQGXE4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GTONyki02KmQpbTEi8wjQuqms4uDXY5hnYarMscBZw9FRzPMk8lv2UG0JVz1XTataalHD+jdGOCZNgfk+ugyP9+HjonA/ZsoSGv/+FWEWW4y0wuPmgmJchNQhqL/U+mbY2f5wUNM9CH97gewt4a1XVX42qUHAlhu6tf8+7Y9BAE= 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=FjehWYOx; 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="FjehWYOx" Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62K9To0f1941698; Fri, 20 Mar 2026 14:12:39 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=NNMqwc Sq7FF1iqjaeODOZEvhzmhOaIpmkEjpWHiujTc=; b=FjehWYOx8No9JdBGPWK7Om 7RFKgBKHG8P9sFVeNeuDzJH6ufvZ55y7FJ7/2AdF8TbZmRJM2V5bhlL5JQXesgL4 +ThahSdcwOU+sFoepD+JD76VFxw3VgWuM4oErhgstCAjzETYhq3UFsir9bhLAlK0 ewZbcUuh5SikK8b0efKRpRWlNIzHJ7XAZzRe4Bw17KOuaTU9Juj0chE0NCNVGhXf l4KMCivB1QCYf2lHim1ozLsf3zFazkhTvorSb4ovlCX+eyPVzGcgMDFSrAjLeqM6 WWeTh36yBqDecYhyNp5QSX66jjaEJem6SgSEd/nI/Jr3T0YI5oy+t/F2QaDsUWQQ == Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4cvy6542j1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Mar 2026 14:12:38 +0000 (GMT) Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 62KDHQxG028452; Fri, 20 Mar 2026 14:12:38 GMT Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 4cwmq1q88p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Mar 2026 14:12:37 +0000 Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 62KECavi43057578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Mar 2026 14:12:36 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 317F02004B; Fri, 20 Mar 2026 14:12:36 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CC61220040; Fri, 20 Mar 2026 14:12:33 +0000 (GMT) Received: from [9.39.23.72] (unknown [9.39.23.72]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTP; Fri, 20 Mar 2026 14:12:33 +0000 (GMT) Message-ID: <8b638b28-9fbf-40f9-8c5a-e6485d9aea2b@linux.ibm.com> Date: Fri, 20 Mar 2026 19:42:32 +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 1/2] sched/fair: consider hk_mask early in triggering ilb To: Peter Zijlstra Cc: K Prateek Nayak , mingo@kernel.org, vincent.guittot@linaro.org, linux-kernel@vger.kernel.org, juri.lelli@redhat.com, vschneid@redhat.com, tglx@linutronix.de, dietmar.eggemann@arm.com, frederic@kernel.org, longman@redhat.com References: <20260319065314.343932-1-sshegde@linux.ibm.com> <20260319065314.343932-2-sshegde@linux.ibm.com> <6f78a46d-9f12-4e42-ae9b-17f3543136e7@amd.com> <20260320114312.GB3558198@noisy.programming.kicks-ass.net> Content-Language: en-US From: Shrikanth Hegde In-Reply-To: <20260320114312.GB3558198@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: Us4lOTNDXmWkNuB-p3TjiQ18RVxJCWaf X-Proofpoint-GUID: Us4lOTNDXmWkNuB-p3TjiQ18RVxJCWaf X-Authority-Analysis: v=2.4 cv=KYnfcAYD c=1 sm=1 tr=0 ts=69bd55d6 cx=c_pps a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=iQ6ETzBq9ecOQQE5vZCe:22 a=XjjZUGcAMD3LgD2hLekA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzIwMDExMyBTYWx0ZWRfX8hLS/wfW/vAv SwrvCVSufvGNOgUAIoBv6HosxHjEz24MAbFAuUqYpBRMsXP9afPNG6Gd5612Rp9nO+7Sd3noZkw +vQH4LIGbcAc6lQEa8WBBTDMEdVMtp8blfxJPdXgdL5MLFnE93SnFkzBf+rFvp3+b5/fBBp/cJG RzXH+2AMXpoHs4MX6Xr/+lQ3R5gA7DwB+fUIMca2F5x3ptWATQ/KUcDGlOGxgp1TvFLnRVav0XI r9fsux9YhA0q3/YzmvOIpj7MxeBWaTSRW/K/BLnBxhRM9L1wkQuBYCt0nknJilnVy1WPNPJeGgi YAwZxmhdg3MIg/tDFYuSbqr5DPAxPxBUmhb6CNvc26v7u2cA5ThYATLrr8UpYKIHG9zZLSdHE1f dLzV6v9QiKGgsVwwOtRtwMsCQnAhJFJLlgEi013mEc3GTgDuv8LfNYvk0B1SKTPSwMQkYzGzu76 AE8MBXK1L/JC1McumXw== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-20_02,2026-03-19_05,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 lowpriorityscore=0 priorityscore=1501 suspectscore=0 bulkscore=0 spamscore=0 impostorscore=0 malwarescore=0 adultscore=0 clxscore=1015 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603200113 On 3/20/26 5:13 PM, Peter Zijlstra wrote: > On Fri, Mar 20, 2026 at 02:49:30PM +0530, Shrikanth Hegde wrote: >> >> >> On 3/20/26 9:07 AM, K Prateek Nayak wrote: >>> Hello Shrikanth, >>> >>> On 3/19/2026 12:23 PM, Shrikanth Hegde wrote: >>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >>>> index b19aeaa51ebc..02cca2c7a98d 100644 >>>> --- a/kernel/sched/fair.c >>>> +++ b/kernel/sched/fair.c >>>> @@ -7392,6 +7392,7 @@ static inline unsigned int cfs_h_nr_delayed(struct rq *rq) >>>> static DEFINE_PER_CPU(cpumask_var_t, load_balance_mask); >>>> static DEFINE_PER_CPU(cpumask_var_t, select_rq_mask); >>>> static DEFINE_PER_CPU(cpumask_var_t, should_we_balance_tmpmask); >>>> +static DEFINE_PER_CPU(cpumask_var_t, kick_ilb_tmpmask); >>> >>> nit. We can rename and reuse select_rq_mask. Wakeups happen with IRQs >>> disabled and kick happens from the hrtimer handler so it should be safe >>> to reuse that and save some space. >>> >>> Thoughts? >> >> May be. but it could be a confusing name. sched_tmpmask? >> >> We could similar stuff already to load_balance_mask, select_rq_mask. >> So, i would prefer to keep it separate. > > But then we keep growing this ad infinitum. > > The more sensible option is to name them after the context and have > get/put accessors that (for PROVE_LOCKING builds or so) verify the > context and maybe even 'lock' them to make sure nobody is trying to use > one for two things at the same time. > > That should make it clearer whats what and improve reuse, no? > We have these: deadline.c:static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask_dl); ext_idle.c:static DEFINE_PER_CPU(cpumask_var_t, local_idle_cpumask); ext_idle.c:static DEFINE_PER_CPU(cpumask_var_t, local_llc_idle_cpumask); ext_idle.c:static DEFINE_PER_CPU(cpumask_var_t, local_numa_idle_cpumask); fair.c:static DEFINE_PER_CPU(cpumask_var_t, load_balance_mask); fair.c:static DEFINE_PER_CPU(cpumask_var_t, select_rq_mask); fair.c:static DEFINE_PER_CPU(cpumask_var_t, should_we_balance_tmpmask); rt.c:static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask) Here, 1. load_balance_mask and should_we_balance_tmpmask are used in the same context all it cares is - I need two cpumask to play with. 2. local_cpu_mask, local_cpu_mask_dl, select_rq_mask are used in independent context - all it cares is all it cares is - I need one cpumask to play with. 3. ext_idle.c: local_* are used the same context. all it cares is - I need three cpumask to play with technically it is doable with one.(but that's a separate story) 1 and 2 are in interrupt disable section, 3 i am not completely sure. I am wondering something like would make sense? DEFINE_PER_CPU(cpumask_var_t, sched_tmp_cpumask1); DEFINE_PER_CPU(cpumask_var_t, sched_tmp_cpumask2); DEFINE_PER_CPU(cpumask_var_t, sched_tmp_cpumask3); Request for a tmp cpumask with number? i.e 2 would say sched_request_tmpmask(0) 1 would sat sched_request_tmpmask(0), and then sched_request_tmpmask(1) 3 would say sched_request_tmpmask(0), sched_request_tmpmask(1) and sched_request_tmpmask(2) Do this if interrupts are disabled. if interrupt are enabled, then maybe do allocation/free instead? That would give us the get/put routines for all cases.