[<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