Re: [PATCH] compiler_types: Introduce inline_for_performance

[Andrew Morton]

On Sun, 18 Jan 2026 15:24:48 +0000 Eric Dumazet <edumazet@xxxxxxxxxx> 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