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 E38081F91E3 for ; Thu, 19 Mar 2026 13:39: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=1773927565; cv=none; b=Yxp1O8oBaAEgrlZZ1KQoaMRyr083fx4gE+l7Bdy4V3DWvQ0sC9Eoz7qDRNP+RD2U+mlypUSpKgBTt3SlyYYXo7dzbOweDgfa4h14uI2RcILoSrWX7xyty0sCf5ByF/SKWED+qtv+5wQUswFnJDO0wpMWPX/0PCmJNqxXufN+5kk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773927565; c=relaxed/simple; bh=M+neiVOqInLutXzqSM/Azf1Zds+U+8zYBol6On07Apk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GcYJEA9ODDLzt3qhcBnxeHBDNAYAHoWeBuMGfFYULBYSjXJo4w7g1tSpHWaPawsm7u9wnJNj40o8mZpqdZX1WTOIwJhebYceK91Hvsd/V/5SM0e/O/G1OgDAzHx2MPdVAUHFLiCPavFK8qoFnRxsLUtlDMcD1wsbWUN2u0lNwjw= 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=iPmpc1uw; 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="iPmpc1uw" 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=Mz23kf6kIVaafpCh6zNxu4LkNMIpe/HZzazjNWs9v38=; b=iPmpc1uwRvLUe6SMenVkFrl9mu JJHwFb+i0cWvuRtBpF1xFlpa7Uz8adhUbkWRve7ZXf4rR2hncrBj2q93HS0GwLfsi7RSup4Sb12bu VBkEk+tUGwjxjo0GfatrbgNps8Q07jPgzpp70YG8vnau8u7Gr50NJnY6UTH/6RgUE9zgX6QuOt8bc Cl2RqpP7yNxsUflA1pDEsXvQ33owaLnTm++v8a0UaM8+jc9Ns4Lh/lM+wUd70GGdmr35yWPTXW7ef J85toFxlDPIOswqMcQsvN9vb8eQW6D0RaPi+0kCjmVeZUK7zhuGI+Y2LSjwVh31aAynqLPBhP1YU/ 1MGF7lvA==; 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 1w3Daj-00000006A2P-34Yg; Thu, 19 Mar 2026 13:39:13 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 10FA630029E; Thu, 19 Mar 2026 14:39:12 +0100 (CET) Date: Thu, 19 Mar 2026 14:39:12 +0100 From: Peter Zijlstra To: Shrikanth Hegde Cc: mingo@kernel.org, vincent.guittot@linaro.org, linux-kernel@vger.kernel.org, kprateek.nayak@amd.com, juri.lelli@redhat.com, vschneid@redhat.com, tglx@linutronix.de, dietmar.eggemann@arm.com, frederic@kernel.org, longman@redhat.com Subject: Re: [PATCH 2/2] sched/fair: get this cpu once in find_new_ilb Message-ID: <20260319133912.GA3558198@noisy.programming.kicks-ass.net> References: <20260319065314.343932-1-sshegde@linux.ibm.com> <20260319065314.343932-3-sshegde@linux.ibm.com> <20260319092030.GU3738010@noisy.programming.kicks-ass.net> <5a7b737b-ecae-4dad-9965-5297991c01bb@linux.ibm.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: <5a7b737b-ecae-4dad-9965-5297991c01bb@linux.ibm.com> On Thu, Mar 19, 2026 at 06:33:19PM +0530, Shrikanth Hegde wrote: > Hi Peter. > > On 3/19/26 2:50 PM, Peter Zijlstra wrote: > > On Thu, Mar 19, 2026 at 12:23:14PM +0530, Shrikanth Hegde wrote: > > > smp_processor_id() is pointless to fetch in the loop. Move it out. > > > No functional change. > > > > Isn't this what compilers are for? > > This is what i see in pseries. > > c00000000028cc7c: 1d 70 80 48 bl c000000000a93c98 <_find_next_and_bit> > c00000000028cc80: 00 00 00 60 nop > c00000000028cc84: 00 00 bd 80 lwz r5,0(r29) > c00000000028cc88: b4 07 7e 7c extsw r30,r3 > c00000000028cc8c: 78 1b 7f 7c mr r31,r3 << This is ilb_cpu > c00000000028cc90: 78 1b 7a 7c mr r26,r3 > c00000000028cc94: 40 18 05 7c cmplw r5,r3 > c00000000028cc98: 78 f3 c3 7f mr r3,r30 > c00000000028cc9c: 5c 00 81 40 ble c00000000028ccf8 > c00000000028cca0: 08 00 2d a1 lhz r9,8(r13) << cpu comes from paca_index > c00000000028cca4: 00 f8 09 7c cmpw r9,r31 > c00000000028cca8: 18 00 82 41 beq c00000000028ccc0 > c00000000028ccac: 8d 0c 04 48 bl c0000000002cd938 > c00000000028ccb0: 00 00 00 60 nop > c00000000028ccb4: 00 00 03 2c cmpwi r3,0 > c00000000028ccb8: 78 00 82 40 bne c00000000028cd30 > c00000000028ccbc: 00 00 bd 80 lwz r5,0(r29) > c00000000028ccc0: 01 00 df 38 addi r6,r31,1 > c00000000028ccc4: 20 00 a5 78 clrldi r5,r5,32 > c00000000028ccc8: 78 e3 84 7f mr r4,r28 > c00000000028cccc: 78 db 63 7f mr r3,r27 > c00000000028ccd0: b4 07 c6 7c extsw r6,r6 > c00000000028ccd4: c5 6f 80 48 bl c000000000a93c98 <_find_next_and_bit> > > > > So, yes it is done inside the loop. But accessing it should be cheap as it is r13 access > which is the paca pointer. > > Since different archs implement it in their own ways > (many would have it cheap, but for some may be costly) > and there is CONFIG_DEBUG_PREEMPT too. > So it would be good to hoist it out of the loop IMHO. Ah, right. And I suppose it isn't generally sound to hoist smp_processor_id() unless you have disabled preemption, and since we can't tell the compiler this, it just never can. Fair enough.