linux-kernel - Re: [patch] x86: phase out forced inlining

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: <20080304164605.GA16379@elte.hu>
Date:	Tue, 4 Mar 2008 17:46:05 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Adrian Bunk <bunk@...nel.org>,
	Alexey Starikovskiy <aystarik@...il.com>, lenb@...nel.org,
	astarikovskiy@...e.de, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [patch] x86: phase out forced inlining

* Sam Ravnborg <sam@...nborg.org> wrote:

> > Subject: x86: phase out forced inlining
> 
> Any particular reason you made the patch x86 specific?

to keep it simple for now. Some of the other 24 architectures are 
seriously under-tested and while we can make sure x86 works well, i dont 
test the others. If it works out fine on x86 it can be generalized.

> > +config OPTIMIZE_INLINING
> 
> Other (not all) config options that deal with gcc behaviour are named 
> CC_*. But they mostly impact gcc options. CC_OPTIMIZE_INLINING would 
> match the naming of CC_OPTIMIZE_SIZE, except in the latter OPTIMIZE 
> refer to the -O option.
> 
> CC_DEFAULT_INLINE may give the right associations?

i really wanted to name it 'optimize' - because that's what it does. We 
just lost 2 years of uninlining advantage due to CONFIG_FORCED_INLINING 
not working and nobody actually connecting the dots that the lack of 
'forced inlining' should have resulted in a 'smaller image' and report 
it as a bug.

> > + test gcc for this.
> 
> Would it be worth here to mention that stuff that really needs 
> inlining should use __always_inle and not inline?

i think people know that, but i'll add it.

> > + */
> > +#ifndef CONFIG_OPTIMIZE_INLINING
> > +# define inline		inline		__attribute__((always_inline))
> > +# define __inline__	__inline__	__attribute__((always_inline))
> > +# define __inline	__inline	__attribute__((always_inline))
> > +#endif
> 
> A quick google did not tell me the difference between inline, 
> __inline, __inline__. But it turned out the december 2005 thread where 
> there was a lenghty discussion about trusting gcc with respect to 
> inlining. It is not the subject of this patch but I just wondered why 
> we need all these variants.

i dont know why they there are so many variants, but all of them seem to 
be used throughout the kernel:

   inline    : 25648
 __inline__  : 1380
 __inline    : 368

so obviously the patch has to cover them.

a few stats about inlines btw:

- in v2.6.24 there were 26452 inlines in the kernel in 8083114 lines of 
  code - or one inline per 305.6 lines of code.

- in v2.6.25-rc3 there are 27396 inlines in the kernel in 8387992 lines 
  of code - or one inline per 308.2 lines of code.

at that rate, all inlines will be removed in about 117.5 kernel cycles - 
which, if we count with 90 day release cycles, will be finished in about 
29 years.

if we only look at include/linux/ files [which have the largest inlining 
effect], the rate of inline removal is in fact negative: in v2.6.24 we 
had one inline per 59.1 lines, in 2.6.25-to-be we have one inline per 
57.9 lines.

so i'm not holding my breath and i'm going for the much more immediate 
benefit of CONFIG_OPTIMIZE_INLINING=y.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/