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 71A2136B07B for ; Mon, 23 Mar 2026 19:37:19 +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=1774294643; cv=none; b=aUIEbalFva1nH4ESYfZajzWvm/wHZ5l+cQtj6Zj+kljN9YXMyQm8FUCokXxpfTdqZ1zJi30QMwvt3aHrkW0FtHH54WAdB8PGehxt/x6t7gPXTHmQTXv95mDhTtc/4xgNaoD+qUsPnIeiBbXxT50MfSFadtFR+jWQKalCZ08gEZg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774294643; c=relaxed/simple; bh=FdkzYuw6Od6aWRXpAYyWZP+34NDkKZ7ElOrrLtjlHVs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=kkjbPvJxPBAN0JV5j7DLeOfkeJOwYDT6MTtbYjv/vYAMyMXZchOGy83bFNv3Umtno9N1mn4NP4zY27z6dbxtpI5q1FfXV3l+oqo8BWW4Pe9W5lyeQCQRLdbaqj/jyi5sP3ozl4hLG4aYY7+L6A7plfRAjyswQ6ossJCAwAN6gIc= 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=mvbt9xOv; 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="mvbt9xOv" Received: from pps.filterd (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62NCgjVA043565; Mon, 23 Mar 2026 19:36:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:date:from:message-id:mime-version :subject:to; s=pp1; bh=TxvrgRR5Ih6ucibj0vRz8+hm++JgQf1mhcb4Xb5rG pU=; b=mvbt9xOviZQRLsQwGh3cXh0Acu6NIOmZlkdrDAWWJhZOwZBoyuh5VnGWg v4JIAA4VdNI0jPphwj0jVvAR8W6zkX2uojhQVU9jyXu2z1Rk15sIs7ut2NssByU5 dRXpvfnbqQwEXkfVXdZE8O+av+cGOLeJ+9C3Qb99gYFqNTWnexBdNi3CfhC8LjIG Gh0ANnphAiSyrDL2OZR4SODxRYz42ovQecSi4jjbs7au+EzOuatLS9KF/TLM9Hmb sdqCwUQg8+zeZRQqcIe1agwZna+GiRmxO+jH19mhNAWyj9rWOIr1/pn0D0oyXrwD c9PAp2Ns1eq1ZOVDITxjWKd/lYR5Q== 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 4d1ky001vc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Mar 2026 19:36:52 +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 62NGiIQ2009143; Mon, 23 Mar 2026 19:36:51 GMT Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4d26nner76-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Mar 2026 19:36:51 +0000 Received: from smtpav03.fra02v.mail.ibm.com (smtpav03.fra02v.mail.ibm.com [10.20.54.102]) by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 62NJancX60031448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Mar 2026 19:36:49 GMT Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 53CEC2004B; Mon, 23 Mar 2026 19:36:49 +0000 (GMT) Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6CE3720043; Mon, 23 Mar 2026 19:36:46 +0000 (GMT) Received: from li-7bb28a4c-2dab-11b2-a85c-887b5c60d769.ibm.com.com (unknown [9.39.24.217]) by smtpav03.fra02v.mail.ibm.com (Postfix) with ESMTP; Mon, 23 Mar 2026 19:36:46 +0000 (GMT) From: Shrikanth Hegde To: mingo@kernel.org, peterz@infradead.org, vincent.guittot@linaro.org, tglx@kernel.org, frederic@kernel.org, anna-maria@linutronix.de, linux-kernel@vger.kernel.org Cc: sshegde@linux.ibm.com, kprateek.nayak@amd.com, juri.lelli@redhat.com, vschneid@redhat.com, rostedt@goodmis.org, dietmar.eggemann@arm.com, mkchauras@gmail.com Subject: [PATCH 0/4] Micro optimise to get this_cpu once Date: Tue, 24 Mar 2026 01:06:26 +0530 Message-ID: <20260323193630.640311-1-sshegde@linux.ibm.com> X-Mailer: git-send-email 2.51.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzIzMDE0MyBTYWx0ZWRfX1PwfP6HI6H9r uRZR+JodxsWvVitjudkttLzl2DFhaPHQ9x/S1m3hP/jrNTplTXWDQOesTLq6HpZ1PDRS89erF97 bDbiXC3GNHqAvxKd0ckVGjybLe0Wd0DE0ObCyuWxhfQcxmu2E2RlyH1pklfDWDl7IXx+g+EbPQw zoJjV7q/3cuHIlKJF7Y9l9ZyCcxwsAfau+rraNtY3aKwxMIdzYsY5lr2g4x/gqWdTDCFuh6okr5 YnyATIqXD9aV9iJqFi7+Rmswpd/TEQ+3benFNLuqJwgWgjV2lf01CsfFHAZ06BQ9U6VjRCNJHuI dCkYsjkBrg52MKRoUamgQS8ez9hFs3LBKC0iFNpxGnEWd3pRjLKddc6oHXL4PLG4SnejpXkH7Y7 soFSIIOhz1pHdSQ6Gh8ioeZPtNY5YmapNhVzEt1GMHf3WC7ieHWtOoAxrblCqGdQNYTWvkdksfk jLh2Fi85LNrcuKh+Mww== X-Authority-Analysis: v=2.4 cv=JK42csKb c=1 sm=1 tr=0 ts=69c19654 cx=c_pps a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17 a=Yq5XynenixoA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=V8glGbnc2Ofi9Qvn3v5h:22 a=VwQbUJbxAAAA:8 a=VnNF1IyMAAAA:8 a=IukFPR1N6lk7oao6mDQA:9 X-Proofpoint-ORIG-GUID: eUTpz2IGC-ponJFIyIFTod30mob2KcE0 X-Proofpoint-GUID: B0UBFe3c0Q6liTZ4ErtIWamlIRLbOPNc 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-23_04,2026-03-23_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 clxscore=1015 priorityscore=1501 malwarescore=0 adultscore=0 spamscore=0 suspectscore=0 phishscore=0 lowpriorityscore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603230143 It was observed that compiler doesn't optimise this block to hoist this_cpu calculations out of the loop in preempt disabled sections. for_each_cpu(c, mask) { if (c == smp_processor_id()) do_something do_something_else } smp_processor_id() could be compiled with CONFIG_DEBUG_PREEMPT=y where it can be used for warnings. So maybe that's one of the reason it can't optimize. __smp_processor_id is arch specific, that maybe another reason. Even on CONFIG_DEBUG_PREEMPT=n, compiler didn't optimize it out of the loop. find_new_ilb dis-assembly in powerpc(CONFIG_DEBUG_PREEMPT=n). c00000000028cc7c: bl c000000000a93c98 <_find_next_and_bit> c00000000028cc80: nop c00000000028cc84: lwz r5,0(r29) c00000000028cc88: extsw r30,r3 c00000000028cc8c: mr r31,r3 c00000000028cc90: mr r26,r3 c00000000028cc94: cmplw r5,r3 c00000000028cc98: mr r3,r30 c00000000028cc9c: ble c00000000028ccf8 c00000000028cca0: lhz r9,8(r13) #This is where smp_processor_id is fetched i.e within the loop body. c00000000028cca4: cmpw r9,r31 c00000000028cca8: beq c00000000028ccc0 c00000000028ccac: bl c0000000002cd938 c00000000028ccb0: nop c00000000028ccb4: cmpwi r3,0 c00000000028ccb8: bne c00000000028cd30 find_new_ilb dis-assembly in x86(CONFIG_DEBUG_PREEMPT=n). ffffffff813588eb: call ffffffff81367b30 ffffffff813588f0: xor %ecx,%ecx ffffffff813588f2: mov $0xffffffffffffffff,%rsi ffffffff813588f9: mov %rax,%r8 ffffffff813588fc: mov %rsi,%rdx ffffffff813588ff: mov 0x29258ba(%rip),%rax # ffffffff83c7e1c0 ffffffff81358906: and (%r8),%rax ffffffff81358909: shl %cl,%rdx ffffffff8135890c: and %rdx,%rax ffffffff8135890f: je ffffffff81358952 ffffffff81358911: tzcnt %rax,%rbx ffffffff81358916: cmp $0x3f,%ebx ffffffff81358919: ja ffffffff81358952 ffffffff8135891b: cmp %ebx,%gs:0x28e7712(%rip) # ffffffff83c40034 #This is smp_processor_id() in the loop. ffffffff81358922: mov %ebx,%edi ffffffff81358924: je ffffffff81358946 ffffffff81358926: mov %r8,0x8(%rsp) ffffffff8135892b: mov %ebx,(%rsp) ffffffff8135892e: call ffffffff81365140 ffffffff81358933: mov $0xffffffffffffffff,%rsi ffffffff8135893a: mov (%rsp),%edi ffffffff8135893d: mov 0x8(%rsp),%r8 ffffffff81358942: test %eax,%eax ffffffff81358944: jne ffffffff813589a4 ffffffff81358946: lea 0x1(%rbx),%ecx Patched kernel on powerpc find_new_ilb disassembly. c00000000028cc5c: 08 00 4d a3 lhz r26,8(r13) It is fetched once. ... c00000000028cc94: bl c000000000a93cd8 <_find_next_and_bit> c00000000028cc98: nop c00000000028cc9c: lwz r5,0(r29) c00000000028cca0: extsw r30,r3 c00000000028cca4: mr r31,r3 ... c00000000028cca8: cmpw cr7,r26,r3 c00000000028ccb8: ble c00000000028cd14 c00000000028ccbc: nop c00000000028ccc0: beq cr7,c00000000028ccd8 c00000000028ccc4: bl c0000000002cd958 In CONFIG_DEBUG_PREEMPT=y, if preemption/irq is disabled, then it does not print any warning. In CONFIG_DEBUG_PREEMPT=n, it doesn't do anything apart from getting __smp_processor_id. So with both CONFIG_DEBUG_PREEMPT=y/n, in preemption disabled section it is better to cache the value. It could save a few cycles. Though tiny, repeated in loop could add up to a small value. This is done only for hotpaths or function which gets called quite often. It is skipped for init or conditional hotpaths such as tracing/events. While it was sent out[1] along with other scheduler change, it made more sense to send it out as separate series after observing a few more falling in same bucket. [1]: https://lore.kernel.org/all/20260319065314.343932-1-sshegde@linux.ibm.com/ Shrikanth Hegde (4): sched/fair: get this cpu once in find_new_ilb sched/core: get this cpu once in ttwu_queue_cond smp: get this_cpu once in smp_call_function timers: Get this_cpu once while clearing idle timer kernel/sched/core.c | 6 ++++-- kernel/sched/fair.c | 4 ++-- kernel/smp.c | 4 ++-- kernel/time/timer.c | 5 +++-- 4 files changed, 11 insertions(+), 8 deletions(-) -- 2.47.3