[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20260118114724.cb7b7081109e88d4fa3c5836@linux-foundation.org>
Date: Sun, 18 Jan 2026 11:47:24 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Eric Dumazet <edumazet@...gle.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>, netdev@...r.kernel.org,
Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <eric.dumazet@...il.com>,
Paolo Abeni <pabeni@...hat.com>, Nicolas Pitre <npitre@...libre.com>
Subject: Re: [PATCH] compiler_types: Introduce inline_for_performance
On Sun, 18 Jan 2026 15:24:48 +0000 Eric Dumazet <edumazet@...gle.com> wrote:
> inline keyword is often ignored by compilers.
>
> We need something slightly stronger in networking fast paths
> but __always_inline is too strong.
>
> Instead, generalize idea Nicolas used in commit d533cb2d2af4
> ("__arch_xprod64(): make __always_inline when optimizing for performance")
>
> This will help CONFIG_CC_OPTIMIZE_FOR_SIZE=y users keeping
> their kernels small.
This is good. __always_inline is ambiguous and the name lacks
commentary value.
If we take away __always_inline's for-performance role then what
remains? __always_inline is for tricky things where the compiler needs
to be coerced into doing what we want?
IOW, I wonder if we should take your concept further, create more
fine-grained controls over this which have self-explanatory names.
mm/ alone has 74 __always_inlines, none are documented, I don't know
why they're present, many are probably wrong.
Shit, uninlining only __get_user_pages_locked does this:
text data bss dec hex filename
115703 14018 64 129785 1faf9 mm/gup.o
103866 13058 64 116988 1c8fc mm/gup.o-after
Powered by blists - more mailing lists