lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20260118160125.82f645575f8327651be95070@linux-foundation.org>
Date: Sun, 18 Jan 2026 16:01:25 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: David Laight <david.laight.linux@...il.com>
Cc: Eric Dumazet <edumazet@...gle.com>, 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 22:58:02 +0000 David Laight <david.laight.linux@...il.com> wrote:

> > 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
> 
> The next questions are does anything actually run faster (either way),
> and should anything at all be marked 'inline' rather than 'always_inline'.
> 
> After all, if you call a function twice (not in a loop) you may
> want a real function in order to avoid I-cache misses.

yup

> But I'm sure there is a lot of code that is 'inline_for_bloat' :-)

ooh, can we please have that?


I do think that every always_inline should be justified and commented,
but I haven't been energetic about asking for that.

A fun little project would be go through each one, figure out whether
were good reasons and if not, just remove them and see if anyone
explains why that was incorrect.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ