From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2F42E6F089 for ; Fri, 1 Nov 2024 20:27:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B0D66B009D; Fri, 1 Nov 2024 16:27:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4399B6B009E; Fri, 1 Nov 2024 16:27:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 28C666B009F; Fri, 1 Nov 2024 16:27:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0562E6B009D for ; Fri, 1 Nov 2024 16:27:08 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id BB672403F4 for ; Fri, 1 Nov 2024 20:27:08 +0000 (UTC) X-FDA: 82738659444.06.E4D394C Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf23.hostedemail.com (Postfix) with ESMTP id 461CC140011 for ; Fri, 1 Nov 2024 20:26:48 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=bdKYNoLR; dkim=pass header.d=linutronix.de header.s=2020e header.b="z/S8Ff0J"; spf=pass (imf23.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730492648; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1xV06QTqGl9nixnpVpVhm4ITfCkevbgwfgxifl3glXs=; b=4BAtKTG8mqb6ifoYQr0WvDkQSiAFDkUzM9gPu8/inp3DVOl/p+ITGaNm8ta1DSUb2qUbnD tT0zzjaQLcKjbA9zkZTwt9ffRFubytAhQttz2vUFEz79yM/OzZm7SnBSU0h7N0cXeKl95J i4xjvO7MF5KJhyQyR47OXhNERPdd4Zg= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=bdKYNoLR; dkim=pass header.d=linutronix.de header.s=2020e header.b="z/S8Ff0J"; spf=pass (imf23.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730492648; a=rsa-sha256; cv=none; b=WinPL06vEjgXWIz8BwHemz00yP3XHHRqNb0A2WbQcgv8JXRGqrGLmTXIaBV6Xi96eIeVlO 6nt+wnPxJKrJfJuyMgGfslnR25oUjW8WSechr/n4NIzfPNguo3w2Ifglhnw3STKCb+FYw3 JUNk9uMk3PHGQ7j/1lCcTOglj1NJ5J0= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1730492824; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1xV06QTqGl9nixnpVpVhm4ITfCkevbgwfgxifl3glXs=; b=bdKYNoLRW/D6u9dVR1Re/YsN9u1+39ZdE7c7n6w6JMSHxUgegbgrQ2/feVQH4Ns2UhxbXv 5R/lMYH3/5wnLbxfNPjnJ28b+8WzHCswX8tJ30IwZIkbQTOpTbNDANbI2rkOU28grnlFqG 6vV1ixY5sS+dLUhowYMcqqeHVGn5/rSUVvyARdl9YNW/1PDIU9wiwP9iRFnY0fkLLqrzEE FQdULVwLCjeZ+djwB0KHPNcn1hotUoCwvvSDsEYT74Nowrcn4ZqHU06Aowwe5wr6qp2RJh DtsZ2zF+0sS/DcC5jxWrAPms2vH29ByFylYP0EVgME3ujZ53UrsAANqMBB7dQA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1730492824; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1xV06QTqGl9nixnpVpVhm4ITfCkevbgwfgxifl3glXs=; b=z/S8Ff0JoHnOXPst4EdLogpr30PKrdNkL8kIbeI27e7fNEc8RRebLhMh+dJv1eMqVIf0ua wm8hdcOmpHV/gmCg== To: Junaid Shahid , Brendan Jackman , Borislav Petkov Cc: Ingo Molnar , Dave Hansen , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Sean Christopherson , Paolo Bonzini , Alexandre Chartre , Liran Alon , Jan Setje-Eilers , Catalin Marinas , Will Deacon , Mark Rutland , Andrew Morton , Mel Gorman , Lorenzo Stoakes , David Hildenbrand , Vlastimil Babka , Michal Hocko , Khalid Aziz , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Valentin Schneider , Paul Turner , Reiji Watanabe , Ofir Weisse , Yosry Ahmed , Patrick Bellasi , KP Singh , Alexandra Sandulescu , Matteo Rizzo , Jann Horn , x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kvm@vger.kernel.org, linux-toolchains@vger.kernel.org Subject: Re: [PATCH 01/26] mm: asi: Make some utility functions noinstr compatible In-Reply-To: References: <20240712-asi-rfc-24-v1-0-144b319a40d8@google.com> <20240712-asi-rfc-24-v1-1-144b319a40d8@google.com> <20241025113455.GMZxuCX2Tzu8ulwN3o@fat_crate.local> <878qu6205g.ffs@tglx> Date: Fri, 01 Nov 2024 21:27:03 +0100 Message-ID: <87cyjevgx4.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 461CC140011 X-Stat-Signature: uzwzonjbdp8mnn1uo54e6bsg5mumojfo X-Rspam-User: X-HE-Tag: 1730492808-823623 X-HE-Meta: U2FsdGVkX183LDCgltqwWsoC9ENHFYvybMaIT4hnXRRfmqvuHMR5IWAgp21mitophYFje9v7mo7D+qo3+bZL8rPcYqS2YnNtjeg0dlHCD3jnsMgR5blQenvMO5MvDdw3n+dfvSMH9CjT8ixmNjeBNkk6ow3LoXC9KsaEA8AaKRuPdvGdgTth0WB8cqcq7zrwJGDT4sSvhEErp21ltZhIyTTwxiEMhsvzphubBNv9na04yBqQoRq0n1hZ1d0HsUMI8of+tDsx4psAE4Yo5iGTiuDtOMjxPhCvrexhJ02vr3ODHwlVdFPoe2XZ/yDdaWWiFIGYLkMe4Ok3wW/r5FaGSuYCFuevzlmw7gcB7Fg0c5/S4JJ/HjaXWa+b4z454Jn6ceoh0x/5llSp+Sj97AWJN2QB7eitac77Tmi9eubVzv3fflfQ4ShSKAa63tUqD2p7S9WAvj0oioTKGwdfFBn4lO2TjbGIwaeo3JcL2MoWeVYwrz74CfsQNdRXJIRGhrOXozIaWKyONrvZtiLy33pwRHMC/FKw/pDV/2tSh3NYNDTtH0k8gmUnPefqCWqnV+M0yNJufxJYAgVQYwTMrx3ti9GyLSvYdY2TLj7Ga4143M1pJDBwar4QY1eKr8Tqzftm6QlKGCTIUzPG+MvD2/Hagj7ilMbKmec6MRIk2NsuHCiYum5lZiVjwVb4bPcq43njaIaJJ3F/b03JpaZjT41GTWnL1NanjxIKLuhF75w6NDGC/90V5Rg51wnxlVwjnjQtm8rubQ9ZOuVEMpzCzFuQvHMNc4co9gBLBbz6UfsvtBxFWl5WcvHgtTdyWVVZfnUaPasOjeqQsbPbzHmJ0c7cZnd77FqieU5DODUgFzZRsRvGINa74JILuRs5uchTnNPW0QdWj3e63eRQ/BChi3pRjkAh6nEFS43RWphQJHBsI3yoyBkayTh13tPwRNXhwTviCs0fn3lTEonohDxJiA4 9vFkZqte DDGG3eD+D06YRISC+/afSIPjpws+SJoFZ2Jf/4VbmBvw8W1tcodDIR9qgy+PzUtEbjC+H32k67ucii9hsZhXBowm21l6BlgCt0d8mFtEpccyohwQqgK5Eod5s7x7dfDGigBEu+u8tH0v0B80mrulnI8DkhDo0cHpRuvis5R9226Bmz8sH2d+iHcXOPBI15CDfs/xP X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Oct 31 2024 at 18:44, Junaid Shahid wrote: > On 10/29/24 12:12 PM, Thomas Gleixner wrote: >> >> I doubt that it works as you want it to work. >> >> + inline notrace __attribute((__section__(".noinstr.text"))) \ >> >> So this explicitely puts the inline into the .noinstr.text section, >> which means when it is used in .text the compiler will generate an out-of >> line function in the .noinstr.text section and insert a call into the >> usage site. That's independent of the size of the inline. >> > > Oh, that's interesting. IIRC I had seen regular (.text) inline functions get > inlined into .noinstr.text callers. I assume the difference is that here the > section is marked explicitly rather than being implicit? Correct. Inlines without any section attribute are free to be inlined in any section, but if the compiler decides to uninline them, then it sticks the uninlined version into the default section ".text". The other problem there is that an out of line version can be instrumented if not explicitely forbidden. That's why we mark them __always_inline, which forces the compiler to inline it into the usage site unconditionally. > In any case, I guess we could just mark these functions as plain > noinstr. No. Some of them are used in hotpath '.text'. 'noinstr' prevents them to be actually inlined then as I explained to you before. > (Unless there happens to be some other way to indicate to the compiler to place > any non-inlined copy of the function in .noinstr.text but still allow inlining > into .text if it makes sense optimization-wise.) Ideally the compilers would provide __attribute__(force_caller_section) which makes them place an out of line inline into the section of the function from which it is called. But we can't have useful things or they are so badly documented that I can't find them ... What actually works by some definition of "works" is: static __always_inline void __foo(void) { } static inline void foo(void) { __(foo); } static inline noinstr void foo_noinstr(void) { __(foo); } The problem is that both GCC and clang optimize foo[_noinstr]() away and then follow the __always_inline directive of __foo() even if I make __foo() insanely large and have a gazillion of different functions marked noinline invoking foo() or foo_noinstr(), unless I add -fno-inline to the command line. Which means it's not much different from just having '__always_inline foo()' without the wrappers.... Compilers clearly lack a --do-what-I-mean command line option. Now if I'm truly nasty then both compilers do what I mean even without a magic command line option: static __always_inline void __foo(void) { } static __maybe_unused void foo(void) { __(foo); } static __maybe_unused noinstr void foo_noinstr(void) { __(foo); } If there is a single invocation of either foo() or foo_noinstr() and they are small enough then the compiler inlines them, unless -fno-inline is on the command line. If there are multiple invocations and/or foo gets big enough then both compilers out of line them. The out of line wrappers with __foo() inlined in them end always up in the correct section. I actually really like the programming model as it is very clear about the intention of usage and it allows static checkers to validate. Thoughts? Thanks, tglx