On Sun, Jan 18, 2026 at 8:47 PM Andrew Morton [off-list ref] wrote:

On Sun, 18 Jan 2026 15:24:48 +0000 Eric Dumazet [off-list ref] wrote:

quoted

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?

Some functions should  not be out-of-line, even if
CONFIG_CC_OPTIMIZE_FOR_SIZE=y

A case-by case study would be needed.

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

mm/slub.c has __fastpath_inline, depending on CONFIG_SLUB_TINY

This probably could also depend on CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE

->

diff --git a/mm/slub.c b/mm/slub.c
index 861592ac54257b9d148ff921e6d8f62aced607b3..a8ca150a90355dd7a812f390c068ff9a7ccc2562

100644

--- a/mm/slub.c
+++ b/mm/slub.c

@@ -224,7 +224,7 @@ do {                                        \
 #endif

 #ifndef CONFIG_SLUB_TINY
-#define __fastpath_inline __always_inline
+#define __fastpath_inline inline_for_performance
 #else
 #define __fastpath_inline
 #endif