From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 AB7DC36826B for ; Fri, 20 Mar 2026 11:43:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774007005; cv=none; b=cgvJEB6zPGtXNCufChOWJD20+ydIXj8vFmlSJBPK5Wy3nieORKKBTx7sVwnrO1A9RrOx5huFLsMokUbONBfBDWbTr64N0BHbFZiEyRZdLFvUheMkqxNaNURxtKcvj8Bp77K0d04M4vyYZjeOtiScJ/yztyS3TB7mFCeUwx/qSU8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774007005; c=relaxed/simple; bh=WzGuYoSsMzbc3CiFGbwCLz4l9vSUaO+R6AmHr3Oe574=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dHHBPtM1f3c5Q01Y+LomzAgFN32K1Gq7zRXGjlcUrJseUQxH2D10b2r3gay0PGalspzHBf3oxQCSsIu10M87aRRW/FtIVmt2CO8iorNESgrdtczFSRK8YfhVaRgxHGkySMdmZC2Gm5IY1v2YkJ8qY52hn+uUxXbYoM53pbkG3eA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=a7Rrxqs0; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="a7Rrxqs0" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=qjsjq2NWmfSZVh+mgjnkRlE2hS/jxyivvatrc1RIGXs=; b=a7Rrxqs0Sz+GBSf7iF9MLrttQp C2dorEpb3mfcNUh0KLHJ9HeYQDvnB8chzZAMp7bvRtDqk2kQf30gXDHjTz/gmTtFn7MU5XBLResWK ITROIFjNgkH7DJFZ2pPr8B/3dmcxdqw5pA+ZgKjHnDAX5Ut5BrL3aHrwP7eKHTmti6DklkB3x+n6N XNPkDswt1/BXDXEVUIdhz3JOLmEHEOZ/0yAShGKgzt69hrm/zFtZu7URRttZj62nij/eGtL7eMcd6 HPQoZp+PLrqpmpHoO25uzfyoiQQpr/Kvg6NZVgYOY9vgsGlY0WuoMMCezf636u3D7hwNGWoffCBUL tCX8GFhQ==; Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1w3YG2-00000007hnA-2bBv; Fri, 20 Mar 2026 11:43:14 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 84A4F302FFB; Fri, 20 Mar 2026 12:43:12 +0100 (CET) Date: Fri, 20 Mar 2026 12:43:12 +0100 From: Peter Zijlstra To: Shrikanth Hegde 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 Subject: Re: [PATCH 1/2] sched/fair: consider hk_mask early in triggering ilb Message-ID: <20260320114312.GB3558198@noisy.programming.kicks-ass.net> References: <20260319065314.343932-1-sshegde@linux.ibm.com> <20260319065314.343932-2-sshegde@linux.ibm.com> <6f78a46d-9f12-4e42-ae9b-17f3543136e7@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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?