From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF3922FF66C for ; Thu, 18 Dec 2025 17:41:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766079706; cv=none; b=aNhoVxvp3JWgfnTW0eeI5+MOrmdZI2DuWfVBDKf1AHvLJsYCael7uPQgdJlJw83LuA7XTNW/XrVx1Sxevx9Ht9OqltW/Zuj3unJuM6dxYL6vmQgBGBkcoazQKiptSl42P4sTrGMbLdDh5JTzuO8VW6zUleOUZJ0A9uIV+7sIcfg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766079706; c=relaxed/simple; bh=Mu8Ia/K4oKyfrYqaapXvxtI1y1Un8wwm2Uhu9Sg0n44=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gJqSBWgxoMjCidex5jq0APoDU7dj0gJf79LJXRe3+q/fNtmARvyXW9SlFHH7WqRe+1zNVEAh5WbVwSe0yAz5O68FADVOYTQZTwanfmYSEnkeQKZDhnfWZNWf6Ft/6hMWHOxXMbGD4nJLlnAoMoUgT0pcgLU72Y1y9x1BzHMHsWw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=EOvGT5cd; arc=none smtp.client-ip=209.85.218.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="EOvGT5cd" Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-b79e7112398so149718566b.3 for ; Thu, 18 Dec 2025 09:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766079703; x=1766684503; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=a/ak692Fy1+E1G3hslywgekSnXBlttdrvubdhINT2zQ=; b=EOvGT5cd7wb1E9k/wxuUrPJNdLr08J75WbVr12FO8uU/CY7nZHCfvms9v4phYMU+SG DDOXfn6MV+M+zI1PKjrQbGunILVVJEZQFT539on+UuztLt8LhTj7uPAsepoM2YVQUM3x qQlT/T2jsVy9Pd8hj0jG3xt7DFu0NBsPaJKjWwksTxDP5qcbUhdYGLfNnWgYAOKed6Fo KAEguYpzyl0W85NFr6IRph3nSgPCsl+nWJIYubQYSEvotY4yzB7Z9TrVtC4cwEGdLJwG bLq7x8vll9md6LeU7hY6G7X0FydIjbRRUuU08S9pJkpgZloWHC0SjSw+aTNLqBKJnqeq E0Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766079703; x=1766684503; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=a/ak692Fy1+E1G3hslywgekSnXBlttdrvubdhINT2zQ=; b=w8N1llNvnU2nMZOktRQ0CaGFcncDofhFlmdo9Y+uTDOCMD++WI8RCUrUbBeqqo+Ypk Z26w3NXJckWaVp2RLKbkswHtUDjndtQOwznu0r5VUo5SgdiTdkWXkWzdrirnUNiEPOE6 1Y+ohFajWPkfg9MbbWp1ChBqzTHRq/iXE1HyPGXIYi5dy/HOqNYqpxuQKEIEz0BucWqq yFZI8zuPz1QuwUmHXfzRtEZ6DXVhc5M6XP3bTWjB1iqlUAie/h1BlthKHlC6LBOpWprH AF8SxcLATrkD72xokriWNZvMEHhfdrwbwb5ljqmkPPdr8q7GpJeS8jE9QR//cC7W7DNe WArg== X-Gm-Message-State: AOJu0YyAryMh9Fufh94A8s2AIP3G4kF+R60hR6zwVXLb48wTHHxU8LNi D3oOyV2BXUmivPdZ3IiLf30A91AGzlLSTi4HZY32c6DJ9o8+bgQR1UV3/QFQLSuk X-Gm-Gg: AY/fxX7p9vkEl6HI+VbjdjXYKyvUj6Rkpb4G26hJSTf0q7KrRdakGrKXb4q2LYf3Cdp NKPj56MSmBlENRSTbVL7VmSv4mo+WFg5uQtNlG5l8ERiYNFRQrm5+WqOC/rFg3tHQ4MECCvqBgW nFcajhNvTrQlP0GtDi+uKttmU8g3L/lz/0jgjQVJ8LH/N//bVXGzOQRZKWUy0Qxa4i8Wdm5dwfb f1qgdMva0cIGRWlcVudfIzq1q/NrjUR8nU23wAESdy2Z9uWnIPLiOaeFHdfYsXDj+dowwBZ985Z M3Mkz0p8N3ZBgu+2Sf5Q/EFjEeEFFjYre97UPUav9Th9fzeojTeiLOO22+eG/CmQAtPmoWOLrlN +zySntD0gYcOHBn2CATUDbnhCcxgXg01BdNWXtTmec7JPhhfrqjgcMANEkWkMl5SNUCXbyI06rC wXAABXGa3sk/WYfMur5yGIQ/O9WOSbsghnEYn88faQhLA8UcsP7tms9Ig= X-Google-Smtp-Source: AGHT+IH6J7qP3GiEYkTXa8S1GSVYuoau/KovUQebCnv8VhFcDz947m00H4vjb84xc/LaOJ+TgHQWTA== X-Received: by 2002:a17:907:972a:b0:b74:352d:6dc1 with SMTP id a640c23a62f3a-b8036f60b1emr16740166b.28.1766079702686; Thu, 18 Dec 2025 09:41:42 -0800 (PST) Received: from [192.168.1.100] ([46.248.82.114]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8037a62973sm1462666b.6.2025.12.18.09.41.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Dec 2025 09:41:40 -0800 (PST) Message-ID: <456bba09-c695-41a8-aa8c-029266ea42c9@gmail.com> Date: Thu, 18 Dec 2025 18:41:39 +0100 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] x86/irqflags: Force a register output in native_save_fl() To: Eric Dumazet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" Cc: linux-kernel , Eric Dumazet References: <20251218095434.1052422-1-edumazet@google.com> Content-Language: en-US From: Uros Bizjak In-Reply-To: <20251218095434.1052422-1-edumazet@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/18/25 10:54, Eric Dumazet wrote: > clang is generating very inefficient code for native_save_fl() which > is used for local_irq_save() in few critical spots. > > Allowing the "pop %0" to use memory : > > 1) forces the compiler to add annoying stack canaries when > CONFIG_STACKPROTECTOR_STRONG=y in many places. > > 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: ... > 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),%rax # <__stack_chk_guard> > ffffffff82067a46: 48 89 44 24 08 mov %rax,0x8(%rsp) > > ffffffff82067a4b: 9c pushf > > // instead of pop %rbx, compiler uses 2 instructions. > 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_irqsave+0x4e> > > // three instructions to check the stack canary > ffffffff82067a61: 65 48 8b 05 b7 15 45 02 mov %gs:0x24515b7(%rip),%rax # <__stack_chk_guard> > ffffffff82067a69: 48 3b 44 24 08 cmp 0x8(%rsp),%rax > ffffffff82067a6e: 75 17 jne ffffffff82067a87 > > ... > > // One extra instruction to adjust the stack. > ffffffff82067a73: 48 83 c4 10 add $0x10,%rsp > ... > > // One more instruction in case the stack was mangled. > ffffffff82067a87: e8 a4 35 ff ff call ffffffff8205b030 <__stack_chk_fail> > > This patch changes almost nothing for gcc, but saves 23153 bytes > of text with clang, while allowing more functions to be inlined. > > $ size vmlinux.gcc.before vmlinux.gcc.after vmlinux.clang.before vmlinux.clang.after > text data bss dec hex filename > 45564911 25005415 4708896 75279221 47cab75 vmlinux.gcc.before > 45564901 25005414 4708896 75279211 47cab6b vmlinux.gcc.after > 45115647 24638569 5537072 75291288 47cda98 vmlinux.clang.before > 45092494 24638585 5545000 75276079 47c9f2f vmlinux.clang.after > > $ scripts/bloat-o-meter -t vmlinux.clang.before vmlinux.clang.after > add/remove: 0/3 grow/shrink: 22/533 up/down: 5162/-25088 (-19926) > Function old new delta > __noinstr_text_start 640 3584 +2944 > 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 > ... > 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 > __end_rodata 606208 602112 -4096 > Total: Before=28577927, After=28558001, chg -0.07% > > Signed-off-by: Eric Dumazet > --- > arch/x86/include/asm/irqflags.h | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-) > > diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h > index b30e5474c18e1be63b7c69354c26ae6a6cb02731..a06bdc51b6e3d04c06352c28389b10ec66551a0e 100644 > --- a/arch/x86/include/asm/irqflags.h > +++ b/arch/x86/include/asm/irqflags.h > @@ -18,14 +18,9 @@ extern __always_inline unsigned long native_save_fl(void) > { > unsigned long flags; > > - /* > - * "=rm" is safe here, because "pop" adjusts the stack before > - * it evaluates its effective address -- this is part of the > - * documented behavior of the "pop" instruction. > - */ > asm volatile("# __raw_save_flags\n\t" > "pushf ; pop %0" > - : "=rm" (flags) > + : "=r" (flags) You should define and use something like ASM_INPUT_RM macro (ASM_OUTPUT_RM ?) instead to avoid penalizing GCC. Please see include/linux/compiler-clang.h. Uros.