From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (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 2805625524D for ; Sun, 21 Dec 2025 21:40:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766353241; cv=none; b=eYKlupnmlromZPBIOXLvVAiIBxjo1Tlldvx3V3YctUM9cT5nRmj/13JMKShD5dn1L9iZUbEqp5juymAzE6b9hg6EQehtBWpvsJG4Dwu8EYux9d4Zp1CkvhdzCUzxpslLQe/sf1JtGKgnZmUQsbtYyB/z39wxcKZkpl0cILLuEuk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766353241; c=relaxed/simple; bh=2ex+uzwelfVlVX4Acl0wqCiIBRNuMQrP/FVUmZ5VePU=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=Qx9LgUzKA84Ds71lsXO/5VVKWGRGRueahYv1WIVgQWcm6T8zLxrtmK29nPEvSBH1GYIZijsKz+21/Kl1UeaP9f8TVUscZNDDKZSgjKGiFtmvQo2dMbH0BYe6rRAd3Cxk+z7+JR7Hp51yxevHapgzph5dSrznsHrX815HpSvWUmk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=BBM5lcvM; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="BBM5lcvM" Received: from ehlo.thunderbird.net (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 5BLLdmW83215144 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 21 Dec 2025 13:39:48 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 5BLLdmW83215144 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025112201; t=1766353189; bh=eKHrNaMzyllLLqXo2tIf9oWh3KzCELAVJHGbL+mqKn8=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=BBM5lcvM3I8nCTpolVF/+QTyznrRtC0twsOpHjcl843YTUtTBCOLdAuhg0YyWta4C HYvk49wqf1cmEOJo3xcalsMOxtIXuAmYytOni8ZsYe4LUsrqtraxbsFocxsXZUHdGY o8pozcgDQDChfDPhDjtviR2efVtAcI8eQ0RrDftlLNlGvt+/U50CwDulrsJ4elyRxi I+v54kGzRJNjVjfvFv1mI6R+HJXtxHz3YReFu9PZYES9ZuZlHZ1eYPOB6+hzGmNXEk ilCQd5mYUWn+LKjUDB4eXOulonGaM4iddtDiAxl5AfwPy6DIj/rflO/CjpbJmK44Ss Nlvd+2TBhY8/Q== Date: Sun, 21 Dec 2025 13:39:48 -0800 From: "H. Peter Anvin" To: Eric Dumazet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Uros Bizjak , Linus Torvalds , x86@kernel.org CC: linux-kernel , Eric Dumazet Subject: Re: [PATCH 2/2] x86/irqflags: Use ASM_OUTPUT_RM in native_save_fl() User-Agent: K-9 Mail for Android In-Reply-To: <20251219112007.2827302-3-edumazet@google.com> References: <20251219112007.2827302-1-edumazet@google.com> <20251219112007.2827302-3-edumazet@google.com> Message-ID: <05B06AD6-0AB2-4E37-A71D-0D917070FF0F@zytor.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=utf-8 Content-Transfer-Encoding: quoted-printable On December 19, 2025 3:20:07 AM PST, Eric Dumazet w= rote: >clang is generating very inefficient code for native_save_fl() which >is used for local_irq_save() in critical spots=2E > >Allowing the "pop %0" to use memory: > >1) forces the compiler to add annoying stack canaries when > CONFIG_STACKPROTECTOR_STRONG=3Dy in many places=2E > >2) Almost always is followed by an immediate "move memory,register" > >One good example is _raw_spin_lock_irqsave, with 8 extra instructions > >ffffffff82067a30 <_raw_spin_lock_irqsave>: >ffffffff82067a30: =2E=2E=2E >ffffffff82067a39: 53 push %rbx > >// Three instructions to ajust the stack, read the per-cpu canary >// and copy it to 8(%rsp) >ffffffff82067a3a: 48 83 ec 10 sub $0x10,%rsp >ffffffff82067a3e: 65 48 8b 05 da 15 45 02 mov %gs:0x24515da(%rip),%ra= x # <__stack_chk_guard> >ffffffff82067a46: 48 89 44 24 08 mov %rax,0x8(%rsp) > >ffffffff82067a4b: 9c pushf > >// instead of pop %rbx, compiler uses 2 instructions=2E >ffffffff82067a4c: 8f 04 24 pop (%rsp) >ffffffff82067a4f: 48 8b 1c 24 mov (%rsp),%rbx > >ffffffff82067a53: fa cli >ffffffff82067a54: b9 01 00 00 00 mov $0x1,%ecx >ffffffff82067a59: 31 c0 xor %eax,%eax >ffffffff82067a5b: f0 0f b1 0f lock cmpxchg %ecx,(%rdi) >ffffffff82067a5f: 75 1d jne ffffffff82067a7e <_raw_spin_lock_irqs= ave+0x4e> > >// three instructions to check the stack canary >ffffffff82067a61: 65 48 8b 05 b7 15 45 02 mov %gs:0x24515b7(%rip),%ra= x # <__stack_chk_guard> >ffffffff82067a69: 48 3b 44 24 08 cmp 0x8(%rsp),%rax >ffffffff82067a6e: 75 17 jne ffffffff82067a87 > >=2E=2E=2E > >// One extra instruction to adjust the stack=2E >ffffffff82067a73: 48 83 c4 10 add $0x10,%rsp >=2E=2E=2E > >// One more instruction in case the stack was mangled=2E >ffffffff82067a87: e8 a4 35 ff ff call ffffffff8205b030 <__stack_chk_= fail> > >This patch changes nothing for gcc, but for clang saves ~20000 bytes of t= ext >even though more functions are inlined=2E > >$ size vmlinux=2Egcc=2Ebefore vmlinux=2Egcc=2Eafter vmlinux=2Eclang=2Ebef= ore vmlinux=2Eclang=2Eafter > text data bss dec hex filename >45565821 25005462 4704800 75276083 47c9f33 vmlinux=2Egcc=2Ebefore >45565821 25005462 4704800 75276083 47c9f33 vmlinux=2Egcc=2Eafter >45121072 24638617 5533040 75292729 47ce039 vmlinux=2Eclang=2Ebefore >45093887 24638633 5536808 75269328 47c84d0 vmlinux=2Eclang=2Eafter > >$ scripts/bloat-o-meter -t vmlinux=2Eclang=2Ebefore vmlinux=2Eclang=2Eaft= er >add/remove: 1/2 grow/shrink: 21/533 up/down: 2250/-22112 (-19862) >Function old new delta >wakeup_cpu_via_vmgexit 1002 1447 +445 >rcu_tasks_trace_pregp_step 1052 1454 +402 >snp_kexec_finish 1290 1527 +237 >check_all_holdout_tasks_trace 909 1106 +197 >x2apic_send_IPI_mask_allbutself 38 198 +160 >hpet_set_rtc_irq_bit 118 265 +147 >x2apic_send_IPI_mask 38 184 +146 >ring_buffer_poll_wait 261 405 +144 >rb_watermark_hit 253 386 +133 >__unlikely_text_end 368 416 +48 >printk_trigger_flush 262 298 +36 >__softirqentry_text_end - 32 +32 >pstore_dump 1145 1164 +19 >printk_legacy_allow_panic_sync 159 178 +19 >netlink_insert 979 995 +16 >console_try_replay_all 268 283 +15 >do_flush_tlb_all 151 165 +14 >__flush_tlb_all 151 165 +14 >synchronize_rcu_expedited 2248 2259 +11 >=2E=2E=2E >tcp_wfree 402 332 -70 >stacktrace_trigger 133 62 -71 >w1_touch_bit 418 343 -75 >w1_triplet 446 370 -76 >link_create 980 902 -78 >drain_dead_softirq_workfn 425 347 -78 >kcryptd_queue_crypt 253 174 -79 >perf_event_aux_pause 448 368 -80 >idle_worker_timeout 320 240 -80 >srcu_funnel_exp_start 418 333 -85 >call_rcu 751 666 -85 >enable_IR_x2apic 279 191 -88 >bpf_link_free 432 342 -90 >synchronize_rcu 497 403 -94 >identify_cpu 2665 2569 -96 >ftrace_modify_all_code 355 258 -97 >load_gs_index 212 104 -108 >verity_end_io 369 257 -112 >bpf_prog_detach 672 555 -117 >__x2apic_send_IPI_mask 552 275 -277 >snp_cleanup_vmsa 284 - -284 >__noinstr_text_start 3072 1920 -1152 >Total: Before=3D28577936, After=3D28558074, chg -0=2E07% > >Signed-off-by: Eric Dumazet >Cc: Uros Bizjak >Cc: Linus Torvalds >--- >v2: use ASM_OUTPUT_RM (Uros Bizjak) >v1: https://lore=2Ekernel=2Eorg/lkml/CANn89iJ+HKXRn7qF4KrT6gghw6CwWcsvoj8= Scw17CkCqhGbk=3DA@mail=2Egmail=2Ecom/T/#mc2322d458f07118580eca7c5fa1f0bc931= c32d30 > > arch/x86/include/asm/irqflags=2Eh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/arch/x86/include/asm/irqflags=2Eh b/arch/x86/include/asm/irq= flags=2Eh >index b30e5474c18e1be63b7c69354c26ae6a6cb02731=2E=2Ea1193e9d65f2000d6de88= 468bee58f2dae9c6cd5 100644 >--- a/arch/x86/include/asm/irqflags=2Eh >+++ b/arch/x86/include/asm/irqflags=2Eh >@@ -25,7 +25,7 @@ extern __always_inline unsigned long native_save_fl(voi= d) > */ > asm volatile("# __raw_save_flags\n\t" > "pushf ; pop %0" >- : "=3Drm" (flags) >+ : ASM_OUTPUT_RM (flags) > : /* no input */ > : "memory"); > >-- >2=2E52=2E0=2E322=2Eg1dd061c0dc-goog > Maybe they should provide an intrinsic for this operation?